Finished sprint goal before the time box
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?
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.
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
See "Flow Optimization at the Sprint Boundary": https://www.scrum.org/resources/blog/flow-optimization-sprint-boundary
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,
@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.
I think if sprint goal is reached before the timebox ,it should be ended with a sprint retrospective in which future sprint lengths to be reviewed as scrum is based on Lean thinking which reduces waste.
carrying other work in this print like refactoring etc will be like just carrying on the sprint since timebox is yet not ever.
Achieving the Sprint Goal well before end of the Sprint is something once a while and not a regular affair. As @Chris Belknap , the remaining time in the sprint should be utilized in below activities :
- Continuous Improvement items from past Sprint Retrospectives
- Work on Tech Debt
- Training so the Dev Team becomes more cross functional
- Additional Backlog Refinement
- Working on the long pending, low priority defects.
In normal scenario, the team hardly find any time to work on the above area. Now since Sprint Goal has been achieved already, this is the best time to use the capacity and effort in this way.
The situation of achieving Sprint Goal before the Sprint ends is very very rare. Sprints end only when the timebox elapses or the Product Owner cancels the Sprint. So I don't think that you can end the Sprint. The Team can definitely take up some extra Product Backlog Items in consultation with the Product Owner if they are confident of completing it as per the Definition of Done.
Maybe your Team can utilize the spare time to prepare itself for the forthcoming Sprints by doing things like:
- Doing Product Backlog refinement with the Product Owner
- Check and try to reduce Technical Debt
- Maybe use a Spike for R&D on some new technology which will be useful for forthcoming Sprints
During the Sprint Retrospective Team can discuss the reasons why this happened. This will help them in better Sprint Planning for the forthcoming Sprints.
I agree with all the above responses-utilizing the remaining working on product backlog refinement, handling technical debt, training and working on spikes will increase team effectiveness, cohesion and efficiency .