Finished sprint goal before the time box

Last post 03:53 pm June 22, 2020
by Daniel Wilhite
5 replies
06:55 am May 2, 2020

It does not happen often, but I was wondering what happens if 2 weeks into a 3 week sprint, the sprint goal has been reached with all items have reached the agreed definition of 'Done'.

Why might this happen?

Perhaps the team has increased their velocity from improving scrum practices, or items that were estimated as X turned out to actually be less work as the sprint backlog emerged during the sprint.

In any case, what does Scrum methodology advise to do in these cases? I have had developers spontaneously pick items off the top of the product backlog, but I think this breaks the rule of not changing the sprint goal during the sprint. Is it acceptable to include more stories in this way? Alternatively, I thought that the sprint should end, but this breaks the rule of the sprint ending when the time box expires.

By ending the sprint, a new sprint can start, with the appropriate Sprint Planning exercise, rather than just including more stories into the current sprint (ones which have not been discussed in a sprint planning exercise)

Any thoughts?

02:48 pm May 2, 2020

Why might this happen?

@David Briffa, You did mention that this does not happen often, so these are cases where your estimation deviated, perhaps because of the feeling that the work chosen would take the entire duration of the Sprint when in fact, as the Development Team worked on it, the work turned out to be less (just as you mentioned in your post). Try to retrospect and find out how you can minimize such occurences.

If you've met your Sprint Goal, then there is nothing stopping the Development Team from pulling in more Product Backlog Items into the current Sprint after discussing with the Product Owner. The Sprint Goal has been met, so it is no longer endangered and therefore it does not change. The additional work is just adhoc work that also needs to meet the Definition of Done.


03:27 pm May 2, 2020

If the Sprint Goal is met early, the "Done" Increment should not be put at risk in any way. Only the PO can end the Sprint, yet there might be other work that can be completed for a self-organizing Dev Team:

  • Continuous Improvement items from past Sprint Retrospectives
  • Work on Tech Debt
  • Training so the Dev Team becomes more cross functional
  • Additional Backlog Refinement
11:55 pm May 2, 2020

See "Flow Optimization at the Sprint Boundary":


04:35 pm June 19, 2020

After reading the responses it is still not clear for me. Is the Sprint Timebox a fix duration (for example: two weeks), or iti a maximum duration?

In the second case, maximum, Sprint culd be finished at PO decision and new one starts inmediately. Is that possible?

Again, is it fixed timebox or it a maximum?

Thanks for advice, regards,


03:53 pm June 22, 2020

@Oscar Vigo Abad.  This is the opening paragraph from the Scrum Guide's section that describes the Sprint. 

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

The words "consistent durations" is where the fixed timebox stance comes from. If you do as you state with your "maximum" suggestion, the durations could potentially be fluctuating widely and you lose any benefit of the timebox. It also makes it almost impossible for a team to develop any kind of cadence and forecast Sprints.  The Product Owner loses the ability to forecast deliverables in a way that can be communicated to external parties.  These are things that Scrum provides.  There are other agile practices that do not have the cadence considerations and for some teams/organizations, those work perfectly well.  But if you are doing Scrum and finding benefit from Scrum, then you are better to stick to a fixed cadence for your Sprint durations.