Is the Sprint over yet?
If a Scrum Team achieves the Sprint Goal early, must they then continue the Sprint?
One of the questions in the Scrum Open assessment asks about the proper time to consider a Sprint as “over”. The correct answer for this particular question is “When the time-box expires”. The answer makes sense since Sprints are fixed length events of one month or less to create consistency.
“Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.” — Scrum Guide, 2020
The answer to this question is usually labelled as ‘obvious’, but what does it mean?
Webster’s dictionary offers the following definition for the verb ‘to expire’:
Expire (verb): to come to an end, such as
a) To exceed its period of validity
b) To pass its expiration date
In all my years as a Scrum Master, I have found that organizations seem to understand the expiration of Sprints as a fixed date. Scrum Teams use that date to plan and to synchronize the development work with other teams and other business events. Organizations see this consistency as a way to help Scrum Teams learn how to be effective and deliver as much value as possible up until that date.
But what about exceeding a Sprint’s period of validity? Apart from when Sprint Goal becomes obsolete, in which case the Product Owner can cancel the current Sprint, there are three things to keep in mind:
- Scrum Teams must create a Sprint Goal by the end of Sprint Planning, so every Sprint must have a Sprint Goal.
- The Product Goal is the long-term objective for the Scrum Team, meaning that more than one Sprint Goal may be needed to achieve the Product Goal.
- Increments at the end of each Sprint serve as smaller steps towards the Product Goal. These are the inspectable artifacts that help the Scrum Team and stakeholders collaborate on what to do next.
I would argue that a Sprint has exceeded its period of validity once a Scrum Team achieves the Sprint Goal. But what can a Scrum Team do if they achieve the Sprint Goal before the time-box for the Sprint expires?
“An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.” — Scrum Guide, 2020
Option 1: Self-organize around the work needed to further advance towards the Product Goal until the time-box expires.
This approach is the most commonly followed by the Scrum Teams I have been a part of.
Suppose every Product Backlog item selected during Sprint Planning meets the Definition of “Done”. Assume the Product Backlog is sufficiently refined. Then, why not start the next most valuable Product Backlog item that would help us get a little bit closer to the Product Goal?
It is a fair question. After all, the premise is that the Sprint Goal has been met. Still, the question must be asked with caution. The Scrum Team should discuss some important topics before making a decision:
- Can the Developers commit to the Definition of “Done” for that PBI? Presenting “Done” Increment during the Sprint Review shows respect to our stakeholders. Moreover, not finishing the work necessary to reach “Done” would mean we incur waste.
- Does it really add value to the Product Goal or are we going to work on that PBI because we can? The latter would be considered wasteful.
- How could the Product Goal be impacted by working on that PBI now? After all, it could have been selected as part of the Sprint during the Sprint Planning but at the time we decided to leave it. What has changed? Are our stakeholders available so we can get their input? They should know that the PBI remained in the Product Backlog at the end of Sprint Planning and they may want to discuss it during the Sprint Review. Moreover, priorities may have changed and new market opportunities may have arised. A Scrum Team may incur waste if they decide to keep working without the necessary inspection at the Sprint Review.
Clearly, starting work just because we have achieved the Sprint Goal is not an easy decision to make, nor we should make it unilaterally.
In my experience, very few Scrum Teams have enough time after achieving the Sprint Goal to add more “Done” Product Backlog items to the Increment. Use remaining Daily Scrums to inspect the Increment and make the necessary adjustments to improve its quality. Who knows, you might gain valuable insights to take to the Sprint Review and Sprint Retrospective.
“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.” — Scrum Guide, 2020
Option 2: Finish the current Sprint and start a new one.
The alternative to starting new work could be to finish the current Sprint and start a new one. Do a Sprint Review to inspect the Increment with your stakeholders and collaborate on possible next steps. Do a Sprint Retrospective to plan ways to increase the quality and effectiveness of the Scrum Team.
To be clear, finishing a Sprint before its time-box expires is conflicting with the Scrum Guide. Scrum allows the cancellation of a Sprint only when the Sprint Goal has become obsolete. Scrum promotes fixed-length Sprints of one month or less to create consistency. Still, some Scrum Teams could take advantage of it.
When I suggest to finish the current Sprint and start a new one when we have achieved the Sprint Goal, most Scrum Teams say the same thing: NO WAY. They normally say things related to stakeholder availability, the logistics of the Sprint Review (room availability mostly), coordination of calendar events for subsequent Scrum events and “other meetings” (*sigh*), etc. This is a fair complaint and I believe it is the main reason the Scrum Guide talks about fixed-length Sprints to create consistency.
Even so, one could argue that the time-box of the Sprint expires the moment a Scrum Team reaches the Sprint Goal (the outcome of a Sprint, along with the Increment) in the same way the time-boxes of the Scrum events expire whenever its participants achieve the intended outcome.
Assume stakeholders are available to attend the Sprint Review whenever we achieve the Sprint Goal (if they weren’t, the Sprint Review would not make sense). What could be the benefits of finishing the current Sprint and starting a new one under this scenario?
- In complex environments, we welcome early feedback to learn and reduce uncertainty. Thus, the shorter the learning cycles, the better. Having the Sprint Review event earlier means that we can Inspect the Increment earlier. We can discuss changes in market needs earlier. We can adapt the Product Backlog to reflect possible next steps towards the Product Goal earlier. The result is an increase in the agility of the Scrum Team and the organization.
“Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame.” — Scrum Guide, 2020
- Achieving the Sprint Goal sooner provides valuable input to both the Sprint Review and the Sprint Retrospective. What has changed that enabled it? What have we learned? If a Scrum Team finds itself in this situation more and more frequently, maybe it’s time to inspect its context and capabilities. Have we sufficiently reduced uncertainty so we can experiment with shorter sprints?
I believe this last point is often forgotten by Scrum Teams and organizations. In my experience, new Scrum Teams are not empowered to decide the length of their Sprints (they should do it as a self-organized team). Thus, they end up with a sub-optimal Sprint length due to management mandates (e.g. every Scrum Team in the organization must work in two-week Sprints).
What factors can guide a Scrum Team to decide on an “adequate” Sprint length? In Mitch Lacey’s The Scrum Field Guide, a Scrum Team can find some questions they need to answer to decide on a sustainable Sprint length. These questions cover several topics:
- Length of the project.
- Customer and/or stakeholder availability for feedback and guidance.
- Familiarity with the Scrum framework (both stakeholders and the Scrum Team).
- Organizational barriers.
- Regulatory issues.
- Technical capacity of the Developers.
- Product Backlog refinement capabilities.
All these topics (among others, of course) are sources of complexity and uncertainty. Every Sprint the level of uncertainty will change (and hopefully decrease), so it makes sense for a Scrum Team to decide it is time to change the length of its Sprints.
Use empiricism to inspect the rate of changes in the market needs of your product and the evolution of the Scrum Team, and adapt the length of the Sprint to improve the agility of the organization.
What could you try under this approach?
- Have variable Sprint lengths and take advantage of time-boxing at the same time. A Sprint would take as long as needed to meet the Sprint Goal but no longer than a set duration (e.g. two weeks).
- Experiment with shorter Sprints with the aim to stick with them when this proves to be better.
Word of caution: Treat the modification of the length of Sprints as an experiment with clear learning objectives. Keep it stable for a while in order to get the expected benefits and create consistency again. Use empiricism to decide on the Sprint length that proves to work better for you.
Endnote
What should a Scrum Team do when they achieve the goal for their current Sprint before the time-box of the Sprint expires? My preference would be to act in one of two ways:
- Self-organize around the work needed to further advance towards the Product Goal until the time-box expires. Avoid starting new PBIs that you may not finish. Focus on increasing the quality of the Increment to improve transparency and collaboration at the Sprint Review. This may lead to modifications to your Definition of “Done”; or
- Finish the current Sprint and start a new one. Do the Sprint Review and Sprint Retrospective events. This may lead to experimentation with the length of the Sprint.
Have you encountered this situation in your Scrum Team? What did you do? What other alternatives have you found useful in your experience?
