While conducting training on Scrum to my colleagues, who are transitioning from waterfall development, there were several questions about Sprint Length.
Here are all I know about Sprint Length:
1. A Sprint is not more than 1 calendar month
- Limit risk to 1 calendar month cost.
- Measurement is preferred to be in weeks over calendar days. This is to reduce complexity in accounting for varying holidays and developer availability.
- Measurement is typically from 1 week to 4 weeks.
- Longer sprints (3 – 4 weeks) have the following disadvantage:
- Hard to stay focused and committed with longer deadlines
- Can lead to procrastination
- Adds more risk and complexity as many changes can happen in longer sprints
- More difficult to plan and implement improvements, reviews and retrospective are far apart
- Complexity increases as there will be several changes implemented on the increment
- When in shorter sprints (1 – 2 weeks) the team cannot produce valuable software that can be usable by end-user, consider increasing the sprint length.
2. Shorter sprints are preferred (2 weeks highly recommended)
- More frequent Sprint Reviews and increase feedback cycles. The team will be more agile to adapt to changes.
- Impediments and risks are highlighted immediately for immediate attention and action
- More opportunities to implement incremental improvements. More effective review and retrospective as the issues and opportunities are still fresh.
- Granularity of stories are more manageable, since they need to fit in a shorter sprint
- For newly formed Scrum Teams, it is recommended to have 1-week sprints for the first 3 sprints and switch to 2-week Sprint for more sustainable development
- The Team will go through the stages (forming, storming and performing) of team development faster
- The Team undergoes a “break-in” period in these initial sprints to immediately expose issues such as lack of necessary skill to deliver increments. The time can be used to assess team velocity for more accurate forecasts.
- When the Development Team is experiencing frequent interruptions that disrupt sprint plans, shorten sprints to align with the frequency of the changes.
- Teams will experience fewer interruptions. Stakeholders can wait for the next sprint.
- When it seems nothing gets done, shorten the sprint to maintain focus and highlight impediments.
- Failing fast and small with shorter sprints than more expensive lengthy sprints
3. Once a Sprint begins, its duration is fixed
- The Sprint is completed when the time-box (sprint length) has expired.
- When the development finishes work earlier, it is not shortened. Development adds more work from the product backlog as agreed with the Product Owner.
- When development did not finish all the work, it is not extended. The incomplete work are re-estimated and put back to the product backlog.
- It can only be shortened when a Sprint is cancelled – when the Sprint Goal no longer makes sense.
4. Sprints have consistent durations (Length)
- Team Velocity can be consistently calculated
- Sprints are Heartbeat of Scrum. Consistency of beat (length) improves predictability. It is easier to forecast how long product backlog items can be finished or how many backlog items can be done at a given time. Increases estimation accuracy.
- Sprint Planning is easier as team members can estimate the amount of work that can be done within a sprint.
- Reduces complexity of scheduling Sprint events, the events become automatic.
- Mike Cohn, in his article, What Happens & When During a Sprint, illustrates Scrum ceremony schedules at different Sprint Lengths
- Increases team participation, since the events are more predictable, members will have lesser probability to skip these events
- Scrum aims to reduce complexity in development. Having consistent sprint length fixes time, quality, and resources. Only scope changes from sprint to sprint.
- Predictability improves synchronization and coordination with other teams
- Development works at a sustainable pace
- Facilitates continuous improvement as sprints can be compared with another
- Improves team motivation as work becomes more sustainable and predictable. It enables the team to have continuous sense of accomplishment
5. Length of succeeding sprints can be change when it makes sense
- Prior to the start of next sprint, usually decided during retrospect, the Scrum Team alters the sprint length of the succeeding sprints for the best balance of Risk Mitigation, Change Frequency, Uncertainty, Value creation ability and business needs.
- Change to sprint length should not be done frequently as velocity becomes meaningless.
6. Sprint lengths should synchronize with events external to the team
- When the development team needs to integrate with other development teams, sprint lengths should synchronize. This can be achieved by having same sprint length or make the longer sprint multiples of the shorter sprints (assuming 2 teams shorter sprint is 2 weeks, longer sprint is 4 weeks).
- Consider having shorter cycles than competitors: if the competitor releases updates every 4 weeks, release yours every 3 weeks.
- Consider expected duration and important milestones (business events) of the project. Sprint reviews and other important events should align. Sufficient feedback cycles (at least 3 before final release – others recommend 6) should also be considered.
- Customer availability to provide feedback should be considered. 1 week sprints may put higher pressure on the customer.
There is no one-size-fits-all Sprint Length. It is a balance among several factors in the project such as those surrounding the stakeholders, the business value, the project risks and uncertainties.
Industry experts recommend 2-week sprints. This is to strike a balance between high-pressured and high-overhead 1 week sprint and a long hard-to-stay-focused-and-committed 4 week sprint.