Skip to main content
Back
X
Back

Scrum Forum

What to do if the team is finishing the sprint to early?

Last post 03:00 pm February 22, 2017
by kathryn lee
16 replies
Author
Messages
05:37 am September 5, 2013

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?

06:09 am September 5, 2013

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.

07:00 am September 5, 2013

> 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.

07:28 pm September 5, 2013

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.

08:43 am September 9, 2013

Why only deploy at the end of the sprint? Why only deploy once a sprint or less? Why not a few times a sprint?

09:26 am September 9, 2013

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.

06:42 am September 10, 2013

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

08:19 am September 19, 2013

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.

08:39 am September 19, 2013

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

02:56 pm September 19, 2013

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.

12:20 pm October 3, 2013

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.

07:35 am November 25, 2013

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.

07:51 am November 26, 2013

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?

08:53 am November 26, 2013

> 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.

10:14 am November 26, 2013

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!

09:06 pm February 14, 2014

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.).

04:55 pm February 21, 2017

I'd like to weigh in on this and pretty much agree with Charles and his comments:

  " 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"."

I think also that the team makes a sprint commitment,  it's therefore a new commitment if they chose to bring in work and that commitment is to get stuff Done (done, done.)  It's not a great mindset to tell a team that they're getting bonus points, what they're doing is making a new commitment.  So it's good to be careful about that when you bring in new work - can you commit to getting it done?  If not, can you split the story to a smaller unit and get that done?  I know it sounds a bit hard, but self-organizing means self-disciplined. 

If the sprint boundaries begin to be degraded (oh i'll just start that new thing sooner) and blurry, then not only metrics get messy, but team mindset gets messy too.  There is always innovation, celebration, automation, dotting i's crossing t's, learning and tasking/preparation that can be served in the 36 hours leading to the end of the sprint. 

 

best,

k