Quick question, what sprint length do you use and why?

My guess is that you answered two weeks, I’m right aren’t I – well at least around 60% of the time.

Rally Software’s 2014 survey, based on 89,115 responses, shows the following results for the percentage of Scrum teams that use each sprint length:

The Scrum Guide being the fount of all knowledge gives the following rule – a sprint is a “a time-box of one month or less”. I don’t want to appear hardline but if your sprints are longer than a month you should really consider if you are doing scrum at all.

Fixed Sprint Length?

When a sprint is in progress it’s duration cannot be changed, unless it is cancelled of course. The scrum master, in collaboration with the development team and product owner can elect, prior to a sprint beginning, to alter the duration.

The process is usually that duration is discussed in the sprint review in response to an issue and investigated within the sprint retrospective. When a collective agreement is reached the scrum master can decide whether change the sprint length, or not. The scrum master should strive to reach a consensus with at least the development team, as an adversarial relationship is not going to operate well at that level.

There is advice stating that if teams struggle to achieve all of the work within the sprint then the duration should be halved in order to force the issue and encourage change. This may be worth trying but really only in agreement with the team as it will be difficult.

Do not change the sprint length frequently as velocity becomes meaningless, meetings become difficult to organize and the team will be disrupted. Having said that do not be frightened to alter the sprint length if the project or team requires it.

One exception to this is the popular practice of running the first three sprints at one week for a new team to force the process under pressure to bed in. The first three sprints are usually all over the place in terms of velocity for a forming team so the risk is low. After the three learning sprints the team will generally revert to two weeks for the rest of the project.

Release sprints or hardening sprints are controversial but used by some teams still transitioning to Scrum. They are usually kept to the length of a normal sprint so as to avoid breaking the team rythm. Using a longer sprint reduces the need for these ‘false’ sprints.

Selecting a Sprint Length

There is a lot of advice out there for selecting the duration for sprints based on risk, return on investment, feedback cycles, market dynamics but really my advice is just to pick two weeks and see how it goes.

The Goldilocks principle specifies that things should fall within defined margins, away from extremes. For most projects four weeks is too long and one week is too short so two weeks is probably just right.

Good overall advice for sprint length is “as short as you can, but no shorter”. If you cannot achieve a completed story with end-user value in a sprint to the product owner’s satisfaction then consider increasing sprint lengths, but only after trying everything else.

Converting teams from traditional methodologies to Agile is a journey, if as a group they feel that they need to start with a four-week cadence due to cultural, environmental or projects issues then accept it – for now.

You will see advice saying to avoid three week sprints, don’t listen – quoting natural cycles and the difficulty of synchronizing three weekly events is all rubbish. Three weeks is the second most popular choice for sprints, in my mind it’s not as good as two weeks (or even one) but at least it is better than four.

Shorter sprints, one week or less are great if you need to innovate faster than the competition and pivot quickly whilst seeking value. Lean start-up, fail-fast, excitement and energy are all heightened in shortened sprints, unfortunately so is the risk of burnout, incomplete work, lower quality and a short-term viewpoint. Day sprints would be great as well but only for the appropriate development.

With multiple teams working on a common product backlog it is important to synchronise sprint lengths. By this I mean that they need to align, not that they need to be the same. For example a HMI team may be running two-week sprints whilst the hardware team is on four-week sprints, they will still align once a month. In this case I would advise against three-week sprints, as they are a pig to align…

As always we have a complication, some teams use sprint zero as a preliminary increment in order to form the team, set up the development environment and perform enough architecture and design so that the project can begin. Sprint zero is limited to a maximum of three times the normal sprint length; with an average two-week cadence this gives a maximum length of six weeks. The Scaled Agile Framework defines an “Architecture Runway” for effectively the same purpose.

Long Sprints

Teams with durations over two weeks often give some of the following justifications:

• It is too difficult to break stories up for shorter sprints and still produce features with customer value. Longer sprints produce a viable product (false argument: improve story refinement)
• It may be easier to have less frequent sprint planning meetings for larger teams (false argument: do better refinement to reduce and focus Sprint Planning)
• It could be considered that shorter sprints do not suit long projects and month sprints may be better (false argument: reducing feedback cycles is always better)
• There is less innovation in shorter sprints as teams will pick a risk adverse method in order to solve an issue, this may not be the most innovative or optimal solution (some validity but can generally be resolved by using spikes to prepare riskier stories)
• Stake holder exhaustion, attending more frequent sprint reviews may not be viable or desirable for customers (some validity: the team would benefit from shorter cycles although the duplication of reviews for less frequently visiting customers is a waste. This is a balance in which a reduced frequency of customer involvement is not ideal but is reality for many projects)
• Manual regression testing is not possible in short iterations (some validity: transforming legacy projects is difficult when testing is still manual, until this situation is remedied it may be better to run longer sprints)
• The product owner may not be available to perform the role frequently enough for short sprints (false argument: the team either needs a new product owner or the PO needs to reflect on their responsibilities…)

I would ask these teams to consider experimenting by switching to two-week sprints for the following reasons:

• It is easier to maintain a bow-wave of six weeks of sprint-ready stories (three times the sprint length) than twelve weeks worth
• The team will be more agile and able to adapt to market and project conditions as there are less prepared stories
• It is generally possible for the team to keep in mind all of the stories within the sprint and co-ordinate better
• Scrum events (excepting the Daily Scrum) are halved in duration for two week sprints over four week sprints, this increases team focus and energy within meetings
• Engineers still remember what they did at the start of the sprint, retrospectives can get slow when trying to remember four weeks back
• Transparency is improved by shorter sprints allowing stakeholders to review and feedback on completed work more often
• Feedback cycles are shorter for stakeholder feedback and also for sprint retrospectives. These frequent checkpoints make project progress easier to assess and future work simpler to plan
• Longer durations allow teams to regress to waterfall within each sprint (ScrumFall)
• Fail fast, if you are going to fail an entire sprint it is better if it is shorter at least
• Shorter sprints increase motivation, four weeks sprint start casual, have lulls in the second and third weeks prior to rushed work in the fourth week to finish. This is similar to student cramming behaviour…
• Shorter sprints tend to get disrupted less by stakeholder interrupts who can often await the end of a fortnight but will rarely wait for a whole month
• Shorter durations encourage teams to work together in order to achieve the forecast work within the sprint, this also encourages teams members to work outside of their comfort areas
• There is a good reason around sixty percent of teams choose two weeks, this is backed up by being the popular choice of many Agile trainers and coaches

Conclusion

Scrum provides great opportunities to inspect and adapt so collaborate to select an initial sprint length and following a bedding-in period of at least two sprints discuss and decide how to move forward.

Do favour shorter sprint durations over longer ones due to the improved feedback cycle but in summary, do what is right for your product and allow the team to decide.

—

Thanks for reading this far and apologies for the long posts, all aspects of Scrum are deceptively simple in theory but have so much depth in practice. The next post will be on the Sprint Goal, should be nice and short – or not. Please sign up if you would like to receive an e-mail whenever new posts are added.