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 and 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 products.
Let’s discuss the length of a Sprint.
First, check what Scrum Guide says:
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.. Scrum Guide 2020
So, ‘one month or less’ still doesn’t answer the question. But it gives us a clue that the aim is to deliver value. To deliver the value we need to create Increments that meet the Definition of ‘Done’.
It suggests that a team should be able to create a “Done” increment and this will provide the minimum length of a Sprint.
The above statement depends upon multiple factors, such as:
- How many developers do we have in the Scrum Team(s)?
- Skills and maturity of the Scrum team?
- Type of product and technology used
- Definition of “Done”.
- How big Product Backlog Items are? ( aim to convert the Product Backlog Items into a ‘Done’ Increment. If PBIs are big and can’t be further broken down without impacting the value then Sprint Length could be longer)
Furthermore, the Scrum Guide also suggests:
When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.. Scrum Guide 2020
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 Developers of the Scrum 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 at a bank, my team was quite proficient in CI/CD and automation practices. Developers’ ability to create “Done” increments was strong and features were small as well. We also needed quicker feedback as it was important to drive the shape and future of the product. To enable that we implemented digital analytics and wanted to collaboratively review the results with stakeholders.
We started with 4 weeks Sprint but very soon we realized it is not working for us. During Sprint Reviews, it was creating rework and frustration. We learnt that we need to make the feedback loop smaller. We changed the Sprint length to 2 weeks and this rhythm was more suitable in our context.
In another example. We were using Scrum in an Automotive company and our initial Sprint length was 2 weeks. When we start the product development work, we learnt that we were not able to convert Product Backlog items into Done increments within a Sprint. This was resulting suboptimal conversations during Sprint Reviews and we were always carrying the Not-Done work to the next Sprint. It started impacting our predictability as well.
In this scenario, we changed our Sprint length to 4 weeks and it worked for us. Our focus came back on delivering value via Done increment and we also started getting quality feedback from the stakeholders.
Keep it Consistent
Once the right length is identified, keep it consistent. It is your rhythm. Scrum Team will learn how much they can deliver and this will help them in better forecasting. The Scrum Teamthen can use this information to set the right stakeholders’ expectations. However, with a caveat that things can still change as product development lies in a complex domain.
Consistent Sprint length enables the predictability by ensuring inspection and adaptation of progress towards goals (Sprint Goal, Product Product Goal)
- Identifying the right Sprint length is key to 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.