The Scrum Guide gives us a maximum one-month timebox for the Sprint. That means while it cannot be longer than a month, it can — and likely needs to be — shorter. So, how do we choose the right Sprint length for our product?
When someone asks me this question, I often quote Ken Schwaber, the co-creator of Scrum, who says, “A Sprint should be as short as possible and no shorter.” Generally, the longer the Sprint, the more complexity, unpredictability and risk we invite.
Use these three questions to determine the right Sprint length
Three questions can help guide our team’s Sprint length decision:
How quickly does the business need to change direction?
If the business needs to take advantage of opportunities or respond to changes in the market quickly, a shorter Sprint length is better. With a shorter timebox, we can change direction quickly if we discover we need to provide something different to deliver a valuable product.
What is our investment risk tolerance?
When we choose a Sprint length, we commit to focusing on the Sprint Goal within that timebox. The Sprint Goal does not change during the Sprint so as to provide the Scrum Team with the stability to create a Done Increment that achieves a meaningful outcome. And, while we might deliver the Done Increment before the Sprint ends, the timebox indicates the maximum amount of time we will invest in a specific direction for the product before inspecting and adapting based on the outcome of the Sprint. The timebox we choose, therefore, comes with a level of risk. The shorter the Sprint, the smaller our “investment risk.”
How much time do we need to produce a usable Increment of value?
How much time we need to create a usable Increment of value that meets our Definition of Done will depend on the Scrum Team’s capability and the complexity of the product. But if the answer to this question limits the business’s responsiveness to change and investment risk tolerance, the Scrum Team must find ways to improve its abilities. That could mean growing team knowledge and skills or indicate a need for process improvements.
Keep in mind this isn’t about planning for a longer Sprint so that we can complete more PBIs. Longer Sprints come with more complexity and unknowns making them more challenging to plan. If the Scrum Team struggles consistently to deliver a Done Increment by the end of the Sprint, it’s likely a sign the Sprint needs to include less work. It probably needs to be shorter too.
Keep Sprint length consistent
Maintaining the Sprint length lets the team learn what they can create in a given period and how members can work best together. Stability and simplicity help us optimize our predictability and manage risk. If the team achieves its Sprint Goal before the Sprint is up, we can work on continuous improvement actions from Sprint Retrospectives, invest in personal development or team building, or plan another small slice of value we can deliver before the end of the Sprint. And sometimes, people need some space for reflection and strategic thinking.
A Scrum Team can change the length of future Sprints but should do this intentionally as part of the team’s continuous improvement. Changing the Sprint length is usually the result of a process improvement that we would identify in the Sprint Retrospective. The new timebox would then apply to all future Sprints.
Final thoughts
Choosing the best Sprint timebox balances business needs, risk tolerance, and team capabilities. Teams newer to Scrum often err on the side of caution with a longer Sprint, allowing them more time to get to a Done Increment. But in my experience, a shorter timebox is what the team needs to become more effective at delivering high-quality, valuable solutions. When in doubt, remember Ken Schwaber’s words, “A Sprint should be as short as possible and no shorter.”
Join me for a Professional Scrum Class
If you want to go deeper to understand how best to leverage empiricism, teamwork, and product value to navigate the effective use of the Scrum Framework, and make intentional decisions about your Scrum Team’s process, join me for Professional Scrum Training.
