What is the best Sprint length? Who decides on Sprint length? Are there any exceptions? What are some of the most common mistakes people make, when making decisions about Sprint length?
Let’s start from grassroots and answer the following basic question: “What is Sprint main goal?” And while looking for an answer, let’s refer to the Scrum Guide, where the goal of each sprint is clearly described as “…increment (a.k.a. PSPI = potentially shippable product increment) that must be in usable condition and meeting DoD (Definition of Done)”. From the Scrum Guide perspective, it is also clear that while being potentially shippable, an increment does not necessarily have to be shipped. Why is it so? For PSPI to be shipped, it must also represent MMP (Minimal Marketable Product) and the decision about what is marketable comes only from Product Owner and it is based on several factors, including long-term strategy and economics.
(Note: End-of-Sprint deliverable, sometimes, is also referred to as MVP (Minimum Viable Product) and is described well by Roman Pichler here.)
Sprint Length and Release Economics
Speaking of economics, lets recall the relationship between Transaction Costs (Shipping) and Holding Costs, also described in “The Principles of Product Development Flow” by D. Reinertsen. By analogy, if applied to Scrum product development, ‘batch size’ would represent a volume of PSPI and ‘cost’ would represent all combined efforts, associated with production deployment (e.g. integration, end-user training, marketing announcements, etc.).
How does this relate to Sprint length?
While each Sprint is supposed to produce PSPI, it is only Product Owner’s decision ,when to release it (MMP), depends on finding a “sweet spot” between the two types of cost: Holding and Transaction, or if spoken, in software development terms, costs of code deprecation/aging and costs of deployment. On the graph above, it is illustrated by the lowest point of Total Cost curve and it is responsibility of Team and Product Owner to determine what it is.
Corollary to having both strategy and economics changing over time, release frequency may change as well. It would be natural to assume that sprint duration and release frequency are related too. Indeed, the need to release more frequently may lead to sprint shortening, and vice versa.
Are there any other external factors that may influence Sprint frequency of a single Scrum team? The most classic example would be Scrum by multiple teams that sprint together (e.g. LeSS, S@S): develop the same product, for the same Product Owner, and share the same a backlog. While release economics principles would still apply, the situation with scaling may become more complex if multiple teams are tasked to select a shared cadence. One assumption comes to mind immediately: if multiple teams sprint together (synchronously), then their shared PSPI (overall output) will be more substantial (“voluminous”) than that of a single team, and from a Product Owner’s point of view, may sooner merge the gap between PSPI/MVP and MMP (more about factors influencing Sprint length below).
In other situations, e.g. in non-scaled settings, individual Scrum teams could be dependent on other teams (Scrum, Kanban, Waterfall groups, etc), separate organizational domains or external vendors that operate on their own cadence. In such cases, product backlog refinement and sprint planning becomes even more challenging. As a result, sprint length, as well as frequency of scheduled production releases may be impacted.
Who Ultimately Decides on Sprint Length?
Just like any other decision about Scrum team dynamics, the decision on sprint length belongs to a team. Nobody should be deciding how to structure or manage work, on behalf of people that actually do it. Neither Product Owner, nor stakeholders, nor management, nor anyone else. Teams that are new to Scrum may experiment with sprint length at the beginning, while trying to optimize to conditions that are very specific to a team’s dynamics. The best time to self-assess and decide if sprint length should be changed is during a retrospective, when decisions about process improvements are made; and it is done by majority voting. Only in rare cases, when a team has a difficulty to reach consensus, ScrumMaster , who owns Scrum process and plays the role of an arbitrator in retrospectives, can step in and help a team make a choice. This should happen rarely, as frequent lack of consensus might be a sign of deeper team dysfunctions. Initially, during team formation, and before ScrumMaster is elected, Scrum/Agile coach may help team with sprint length selection. Mike Cohn describes his personal experience in a similar situation here.
Factors to be considered while selecting Sprint length?
As a rule of thumb, sprint length should not be shorter than 1 week and should not be longer than 4 weeks. If there is a strong reason to make sprints shorter than 1 week (e.g. could be driven by production release frequency requirements), Kanban, instead of Scrum, could be considered, since it offers, on demand and almost instant, release capabilities. On the other hand, extending sprint length beyond 4 weeks may lead typical challenges of waterfall (sequential work, silos, hand-overs).
Statistically, anywhere between 1 and 4 weeks, a team should be able to establish a steady and healthy cadence to do product development.
Shorter sprints do have certain advantages:
- More frequent sprint reviews and retrospectives – shorten feedback loops that allow applying improvements to product and process development, respectively.
- Shorter sprints require lighter sprint planning and, subsequently, reduce the risk of going too deep into a product backlog and selecting items for a sprint that do not meet DoR (Definition of Done) and are not INVEST-able.
Shorter Sprints may also bring some potential challenges:
- For example, the ratio of time spent on sprint preparation and process management to time spent on actual product development could be high – too much procedural overhead.
- Additional important prerequisites must be met, before moving teams to shorter sprints. For example, if a sprint becomes too short (e.g. 1-week) and there is no full test automation and no TDD, then a team may have a difficult time, keeping up with testing: after completing a few sprints, as the amount of code base increases, manual testing will fall behind. As a result too much work may fail DoD by Sprint-end.
Relationship between Sprint length and Scrum Maturity
It would be reckless to claim that there is a direct cause & effect relationship between sprint length and maturity. Some research indicates (some was done by Jeff Sutherland) that for as long as a sprint is under 1 month, there is no strong and immediate correlation between sprint length and performance. But anything beyond 4 weeks lowers performance and introduces elements of waterfall dysfunction to a team’s dynamics.
What is, by far, more important than sprint length is sprint length consistency. While in early stages of sprinting, it is normal for a team to experiment with sprint length, if length “juggling” continues into later sprints or happens ad-hoc, it could be viewed as a sign of deeper problems. Some teams falsely believe that by periodically extending a sprint they will be able to get more work to Done state. Thinking more systemically, this is a false assumption, as cadence- and task-switching, especially done by multiple teams, can significantly lower overall output. Further, inconsistent sprint length will lead to difficulty of sprint planning, unstable velocities and unreliable long-term forecasting.