Forums

By posting to our forums you are agreeing to the Forum terms of use.
What to do if the team is finishing the sprint to early?
Last Post 14 Feb 2014 08:06 PM by Richard Lynn Paul. 15 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Anton Kalcik
New Member
New Member
Posts:5
Anton Kalcik

--
05 Sep 2013 04:37 AM
    We have endless discussions how to handle if the team is finishing the sprint to early. I know that basically should be the sprint planned as a challenge. But we have from time to time situation when the team is finishing the sprint earlier as expected. My question is how should we handle the situation? Our Scrum Master tends "to replan" when we have the possibility to attach the new stories for the rest of the time to the current sprint. But we are running into the danger to "destroy" successfully completed sprint if we are not finishing the new stories. The next option could be end of the sprint and starting the new one. But the Scrum Master means that this is problem for the velocity measurement, what could be correct. What do you mean?
    Sowatech
    New Member
    New Member
    Posts:6
    Sowatech

    --
    05 Sep 2013 05:09 AM
    Be warned. Until now we failed to implement scrum so my opinions are purely theoretical. :-)

    The problem with the velocity is, that your "real" velocity is higher than the number of points you had in the sprint, because you could have achived more. So if you plan the next sprint based on that number you will have not enough points in it and probably finish it to early, too. So I think your Scrum Master is correct.

    The problem of "refill" or adding items to the running sprint is (albeit other problems) a psychological one. It destroys the feeling for "achiving the goal" and could lead to a kind of "Sisyphos" syndrome and surely demotivates the team to try to finish work to early next time.
    I think it would be best (don't know if it is "good" scrum) to finish the sprint early and start the next and take into account that the velocity is actually a little bit higher, than the numbers tell you. Perhaps you could add some percentaged number based on the percentage of time you spent, but I think a rule of thumb will do either.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    05 Sep 2013 06:00 AM
    > Our Scrum Master tends "to replan" when we have the possibility to attach the new stories
    > for the rest of the time to the current sprint.

    That's good, and I hope he or she involves the rest of the Scrum Team. Continual replanning is good in Scrum. However, changing a Sprint Goal is not.

    > But we are running into the danger to "destroy" successfully completed sprint if we are not
    > finishing the new stories.

    Nonsense. The Sprint Goal has been achieved. The problem seems to be one of underestimation and the reasons behind this should be explored in your next retrospective.

    > I think it would be best (don't know if it is "good" scrum) to finish the sprint early and start the next

    No, the Sprint must complete it's timebox. Replan and consider bringing work forward with the approval of the product owner, or paying back some technical debt or doing backlog grooming.
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    05 Sep 2013 06:28 PM
    I'd pull in more stories. The backlog should be groomed enough that the team is already familiar enough with the functionality to begin (and learn more as they delve into it).

    The answer also depends on if you're deploying every sprint. If so, I could see potential danger in adding more, not completing them and not having a "ready for prod" product at the end of the sprint. If that's the case, I could see an argument for ending the sprint early. Even then, if you can have those incomplete stories still in a deployable state, I think its better to keep the sprints at the same rhythm.
    Philipp Eisbacher
    New Member
    New Member
    Posts:32
    Philipp Eisbacher

    --
    09 Sep 2013 07:43 AM
    Why only deploy at the end of the sprint? Why only deploy once a sprint or less? Why not a few times a sprint?
    Robert du Toit
    New Member
    New Member
    Posts:38
    Robert du Toit

    --
    09 Sep 2013 08:26 AM
    Everything has to be tested before it can go live. We can't push individual stories in our deployment setup, so we can't deploy until everything started is Done.
    Philipp Eisbacher
    New Member
    New Member
    Posts:32
    Philipp Eisbacher

    --
    10 Sep 2013 05:42 AM
    We fixed this with our branching model and can start in the sprint with next release features, and are still able to release the old version or make bugfixes in it to work immediatly on the feedback we get
    adascalu
    New Member
    New Member
    Posts:6
    adascalu

    --
    19 Sep 2013 07:19 AM
    The SM is correct to try to add.

    However, keep in mind the following:
    1. your committment for the sprint has been satisfied. whatever you add is "bonus".
    2. unless you are delivering to actual production each sprint (not a good system, because it puts gratuituous pressure on the commitment), it doesn't really matter if you finish your addition (all that matters is that there is no idle time).
    3. you should be easily capable of adding something realistic (eg: look at your story point burndown for the sprint and compare that against the remaining time to see which story to add).

    If you do that, then the PO will be able to safely adjust the team's velocity.
    Matthias Frey
    New Member
    New Member
    Posts:2
    Matthias Frey

    --
    19 Sep 2013 07:39 AM
    Hello,
    no, no no. SM is not correct an should read the scrum guide. Its not the task of the SM to add, but to help the team to learn and do good work.
    In this case it is the team who have to decide what to do. The work is done. They can make a party, play silly games, may doing some further education, may doing some refactorings or ask the PO if there is something useful to do. They may pull, but nobody outside the team may push
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    19 Sep 2013 01:56 PM
    It is completely up to the Dev Team to decide how much work to take on in a sprint, and this includes the ownership of deciding when to take on more scope in a sprint. If they do choose to take on more work, then the Dev Team decides "how much", and the PO decides "which PBI". Ideally, it should be a PBI that can be finished by the end of the Sprint, because we want to make sure we are delivering a PRI(potentially releasable increment.) However, there are other ways to achieve a PRI even with a PBI that carries over.

    In general, if the "finish" is a day or two before sprint end, I tend to coach teams to spend the time either:
    a) adding a small PBI
    b) learning about test automation (as most Scrum teams have a deficiency in this area), or
    c) investigating the upcoming PBI's -- but not starting work on them yet, or
    d) working on some other sort of "improvement" activity, but never "refactoring".^1

    If the finish is farther in advance than a day or two, then I coach that they should probably take on more work.

    In all cases, I coach to inspect and adapt and be sure to discuss in the retro.

    Some teams I've coached have decided to have a PBI or two already tasked out and ready to go "on deck" in case this happens. A couple of rules on that though -- 1. No one starts the on deck work without the normal discussion between Dev Team and PO -- and PO still has the right to select a different story to be brought in. 2. I coach the team and org what a sustainable pace means and that outside (outside the Dev Team) pressure to take on more than desired is a violation of Scrum.

    ^1 I don't really believe in "refactoring" except when it involves the current PBI you are implementing, as part of TDD, with already existing automated tests.
    Anton Kalcik
    New Member
    New Member
    Posts:5
    Anton Kalcik

    --
    03 Oct 2013 11:20 AM
    This is very interesting discussion! I agree with that underestimation should be discusses in the retrospective! But adding the new story is only allowed, when the story has the something to do with the Sprint goal and the Team is committed. Otherwise the Sprint cancellation.
    Olivier Ledru
    New Member
    New Member
    Posts:31
    Olivier Ledru

    --
    25 Nov 2013 06:35 AM
    The Scrum Guide is crystal clear : "If the work turns out to be different than the Dev Team expected, they collaborate with the PO to negociate the scope of Sprint Backlog within the Sprint".

    For me, "different" means they overcommit or they undercommit. As soon as the Dev Team see they deviate from the goal, they should be transparent and negociate with the PO.
    Fabio Simeone
    New Member
    New Member
    Posts:14
    Fabio Simeone

    --
    26 Nov 2013 06:51 AM

    Posted By Olivier Ledru on 25 Nov 2013 07:35 AM
    The Scrum Guide is crystal clear : "If the work turns out to be different than the Dev Team expected, they collaborate with the PO to negociate the scope of Sprint Backlog within the Sprint".

    For me, "different" means they overcommit or they undercommit. As soon as the Dev Team see they deviate from the goal, they should be transparent and negociate with the PO.


    Olivier, this has been a problematic point during my studies for PSM. I tough the Sprint Backlog may change in accordance with the PO, but only if the Dev Team may have overcommited the work to be done. Reading the other posts here, i understood that if the Dev Team has already finished all of his tasks for the Sprint, more work can be done, but it is a "bonus" and even if the Team fails to deliver this bonus, the Sprint Goal would be achieved. Am i correct?

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:562
    Ian Mitchell

    --
    26 Nov 2013 07:53 AM
    > if the Dev Team has already finished all of his tasks for the Sprint, more
    > work can be done, but it is a "bonus" and even if the Team fails to deliver
    > this bonus, the Sprint Goal would be achieved. Am i correct?

    Yes you are correct, assuming that any undone "bonus" work does not compromise the delivery of the increment.
    Fabio Simeone
    New Member
    New Member
    Posts:14
    Fabio Simeone

    --
    26 Nov 2013 09:14 AM

    Posted By Ian Mitchell on 26 Nov 2013 08:53 AM
    > if the Dev Team has already finished all of his tasks for the Sprint, more
    > work can be done, but it is a "bonus" and even if the Team fails to deliver
    > this bonus, the Sprint Goal would be achieved. Am i correct?

    Yes you are correct, assuming that any undone "bonus" work does not compromise the delivery of the increment.


    Perfect Ian, thanks a lot!
    Richard Lynn Paul
    New Member
    New Member
    Posts:3
    Richard Lynn Paul

    --
    14 Feb 2014 08:06 PM
    We just started on the tasks for the next Sprint (got a head start). While in release planning we had many Sprints roughly planned out, we always had 2 or 3 Sprints planned in detail, though they could, of course, change until those later Sprints started (and sometimes did as we were agile about responding to the market, customers, etc., etc.).
    You are not authorized to post a reply.


    Feedback