It’s common to have an agile coach heater who will tell you that a Scrum team must use two-week sprints. Some recent analysis, though, shows that different timeboxes can have different effects on your product deliverables. Larry Maccherone, a former data scientist at , dug into the data they had for many thousands of teams and sprints. Some of that should make us take a hard look at some of our preconceptions about sprint lengths and desired outcomes.
Typical Sprint Lengths
The original sprint or iteration lengths were intended to be short time boxes. The goal of agile methodologies was to keep work focused and deliver working software frequently. eXtreme Programming recommended iteration lengths of one to three weeks and the team could modify the lengths as needed. If the team was working on something a little more complicated they could extend the iteration length to give themselves enough time to complete it. And they could shorten the iteration length if it was easier or a smaller chunk of work. I worked in this environment and while it can work, it a little more disruptive than standard cycles.
The big push now is less on the actual sprint length and more on the cadence or rhythm of the sprints. Starting on a Wednesday and ending on a Tuesday, for example, can help teams get a clear vision and cadence to their work. It helps team members plan vacations and manage workflow. And consistent sprint lengths help the team get a good “feel” for how much work they can do in a sprint. In scaled models, it ensures that we can align teams. Today, most teams use a sprint length of two weeks, but this isn’t prescribed anywhere.
But the Scrum Guide Says…
No, it doesn’t. The doesn’t say anything about two-week sprints. There is a common belief that the Scrum Guide dictates sprint lengths. I mean, it does say things like:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. (emphasis mine)
– Scrum Guide
But it doesn’t say anything about a sprint needing to be two weeks long. Never has. It does say this, though:
Each Sprint may be considered a project with no more than a one-month horizon.
– Scrum Guide
A lot of what’s happened is that two weeks is a “” sprint length. I use it very frequently with teams because of my experience with agile. As a team member, I can remember back two weeks pretty well. One week isn’t a very good length of time to get things done and three-week sprints make it hard to recall what happened in week one. So two weeks is a good intermediate length for a sprint.
The Research
The problem is that when we look at the results of different sprint lengths, we find that they equate to different kinds of benefits. Despite there being a preponderance of advice to make sprints two weeks long, a lot of people have tried a lot of different sprint lengths. And the results are fascinating.
Larry Maccherone compiled this information when he was at Rally Software. I saw him present the information at and I was more than a little surprised by the results. I would strongly recommend looking at the whole presentation – it has some pretty interesting data. He measured four different aspects of sprint length: productivity, predictability, responsiveness, and quality. Here’s what he found.
One Week Sprints
Teams that worked in one-week sprints tended to have higher productivity than teams that worked in longer sprints. The quality was generally lower for those teams, but they produced more work over time than other teams. Responsiveness was also the highest among the five sprint ranges he examined, but it was very closely followed by two-week sprints. Overall performance (as measured by all four dimensions) was second-best among all of the sprint lengths tested.
Two Week Sprints
This is the standard sprint length and provided, overall, the best blend of benefits to all four dimensions. While productivity wasn’t as high as one-week sprints, the quality was much better and responsiveness and predictability were solid. Overall performance was best among all of them measured.
Three Week Sprints
Quality was the main benefit in three-week sprints. It’s not as good as four-week sprints but compared favorably against two-week sprints in productivity and predictability. The only downside was the responsiveness element, which makes sense. The overall performance was third-best among all of the sprint lengths measured.
Four and More Week Sprints
Larry actually broke out “four weeks” and “five or more” weeks, but I think we can safely lump them together. Generally speaking, four weeks is a short project and five or more is just waterfall by another name.
The main benefit of longer sprints was that quality generally improved over shorter sprint lengths (three weeks or less). Otherwise, overall performance was lower than the others measured and responsiveness suffered the most, as you’d expect. Predictability and productivity were relatively unchanged from shorter sprint lengths.
The challenge, of course, is that we’re extended the feedback cycle and not “failing fast” or getting rapid feedback from our customers. The longer the sprint, the more risk we incur. I would vigorously argue against any sprint length that exceeds three weeks for these reasons.
@ Velocity
Our teams typically use whatever sprint cadence and length our clients are using with their internal teams. If the client is brand new to agile, which a surprising number are, I always coach them to look at two-week sprints to start. Mostly because it’s a “Goldilocks” sprint length but also because the data backs up that it’s the most balanced sprint length. We can always look at modifying it to meet a client’s needs – or those of the team – when the team matures.
For clients that are using sprint lengths longer than four weeks, though, I recommend that the team does work in shorter sprints that are part of a larger sprint for them. This gives us an opportunity to demonstrate that shorter sprint lengths can be more productive and more responsive without needing to change their internal cadence. And I’m always willing to coach them on how to make those adjustments internally…
Closing Thoughts
Before reading the research that Larry Maccherone did, I was a strong proponent of two-week sprints because of my experience in development. Now that I’ve seen the data, I am a better-informed coach and feel like I can help my teams excel in those aspects where they need improvement. And while I still start teams off with two-week sprints, it’s clearer how we may want to experiment in the future based on the information. It’s good to know what’s available. And …
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)