A student in Scrum class: Lavaneesh, really loved what you said about Scrum so far. But how long should our Sprint be? Did you say less than a month but 1 week, 2 weeks or 1 month? I am confused.
Me: ‘It Depends’
The above question is one of the most common questions asked during my classes. So, let’s explore this ‘It Depends’.
Sprint is the container of the other four Scrum events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The timebox of Sprint provides focus on things that are imminent and valuable with an aim to meet the Sprint Goal.
The Sprint works as a closed feedback loop where bottlenecks, inefficiencies in the processes and practices are identified through regular inspection and adaptation. This enables the team’s commitment towards continuous improvement and delivering high quality, valuable product.
First, check what Scrum Guide says:
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. Scrum Guide
So, ‘one month or less’ still doesn’t answer the question. But it gives us a clue that the aim is to create a “Done” increment which is potentially releasable that Product Owner can choose to release.
It suggests that a team should be able to create a “Done” increment and this will provide the minimum length of a Sprint.
Above statement depends upon multiple factors, such as:
- How big is the Development team?
- Skills and maturity of the Development team?
- Type of product and technology used
- Definition of “Done”
- How big Product Backlog Items are?
Furthermore, the Scrum Guide also suggests:
When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Scrum Guide
So, Sprint length also depends upon how complex and volatile an environment is.
It will drive how often the feedback should be received so that the Scrum team can inspect the product increment and reduce the risk of building the wrong thing.
So, what contributes to the complexity:
- How quickly are customers needs changing?
- How quickly are the market conditions and competition changing?
- How stable is the technology and proficiency level of the Development Team?
- How long can the Scrum team wait without Stakeholders’ feedback to maximise the value of what they have built?
Inspect & Adapt
When I was working on a digital product and team was quite proficient in CI/CD and automation practices. The Development team’s ability to create “Done” increment was strong as well as features were small. We also need quicker feedback as it was driving the shape of the product. To enable that we also had digital analytics and collaboratively reviewing results with stakeholders.
We started with 4 weeks Sprint but very soon we realized it is not working for us. It was causing us rework and frustration. We changed it to 2 weeks and this rhythm was more suitable in our context.
Keep it Consistent
Once the right length is identified, keep it consistent. It is your rhythm. The Development team will learn how much they can deliver and this will help them in better forecasting. Product Owner then can use this information to set the right stakeholders’ expectations. However, with a caveat that things can still change even within a Sprint.
Consistent Sprint length enables the predictability by ensuring inspection and adaptation of progress towards goals (Sprint Goal, Product Vision)
- Identifying the right Sprint length is key for the Scrum team’s success.
- it depends upon multiple factors contributing to the team’s ability to create “Done” increment and complexity in the environment
- Once the right length is identified, keep it consistent to create a rhythm that will enable predictability.
Hope you have enjoyed the article. If, you have then please share with your friends and colleagues. Also, provide me with feedback and your thoughts on the subject.