In Scrum, when is a sprint over?
A sprint is one of the core concepts in Scrum. In fact, it is one of the five events in Scrum (along with Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective). A lot of people get stuck trying to figure out when a sprint is really over. To understand this, you need to understand the purpose of a sprint and why it is timeboxed.
What is a sprint?
A sprint is the fundamental unit of time in Scrum. It is a timebox (a specific and enforced length of time) in which a Scrum team attempts to create on or more product increments. All of the Scrum events (Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective) happen within a sprint.
There is no activity outside of a sprint. Once a sprint ends, the next sprints starts immediately, and the sprint cycle begins again. There are no special sprints like “sprint zero”, or “hardening sprint” or “release sprint”. Each sprint the team is meant to move some product backlog items to Done, and produce a product increment.
And most importantly of all, a sprint is strictly timeboxed – usually two weeks, though it can be up to a month long.
Why is it timeboxed?
The sprint timebox is very important. Teams have to respect the timebox and keep to it, i.e. ending the sprint and starting a new sprint once the timebox is up.
It is sometimes tempting for a team to let a sprint “drag on” an extra day or two, to try and complete some items, but this defeats the whole point!
If a team does that, they can keep doing it, and do it more and more. This is going back to the Waterfall days, where releases get pushed further out and out. Since teams want to get all their scope into a release. Before you know it, you can be back releasing every six months!
The strict timebox ensures there is a simple regular pattern, or cadence, where a team stops and inspects its latest product (in the sprint review) and the team itself (in the sprint retrospective).
When is a sprint over?
The short and simple answer is that a sprint is over when the sprint timebox ends! (at whatever cadence the team has chosen for the sprints, i.e. two weeks, one month, one week, etc).
A team can choose to change the timebox for their sprints (i.e. the team can choose to move from two week sprints to one week sprints or vice versa), but that is not a one-off change. That new timebox becomes the standard timebox for all sprints from there on (until the next time a team wants to change the timebox).
A sprint is not over when a product increment is built or released. The team just continues working on further backlog items. They may even produce another product increment that sprint. (There is nothing in Scrum that says you can only release one product increment each sprint!).
A sprint is also not over when the Sprint Goal has been achieved. In the happy situation that there is still some time left in the sprint, the team can choose to perform whatever work they like in the remaining time. This could be to work on some more product backlog items, pay down some technical debt, look at some continuous improvement items, and so on.
The important thing is that the regular timebox is respected.
What other ways can a sprint end?
There are only two other ways a sprint can end.
One is if the Product Owner decides to cancel the current sprint. That is an extreme case that should happen very rarely. The only reason given for this in the Scrum Guide is that the Sprint Goal has become obsolete. That might happen for a variety of reasons, but they should not happen often. It is almost always more valuable for the team to continue and complete the work they have planned for that sprint.
There are no other ways mentioned in the Scrum Guide. The only one I can think of is an even more extreme and hopefully rare example. That is if the product or team itself ceases to exist. If a team is in the middle of a sprint and for whatever reason, the organization decides to stop all work on the product or stop funding the team, then that sprint would obviously end.
The organization might want to fund the team for the remainder of the sprint, but if the product itself is obsolete or no longer funded, they might want to save some money by not completing the in-flight work in the sprint.
Summary
So hopefully this article has cleared up the question about when a sprint is over. Do you have any other ideas or thoughts on this matter? Please let me know in the comments! I will read and reply to every single one.
