3 Reasons for Using Sprints (and Why They May Be Bad)

This is not a post bashing Scrum. It’s the most popular agile methodology for a reason and I really appreciate how it has brought agile thinking and practices to the mainstream. It’s a blessing that these days you can talk about a “daily stand-up”, “sprint” or “retrospective” almost anywhere, and people will know what you are talking about.

However, Scrum is also a product of its time. It emerged in a world where frequent, incremental releases were, let’s say, not the standard. I hesitate to use the term “waterfall” because it’s so often used as a straw man, but you get the idea… If you read the Scrum Guide it’s clearly written against that background as it compares itself to long projects with no iterations:

Each Sprint may be considered a project with no more than a one-month horizon. […] When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

In that context it’s hard to argue against what Scrum proposes. I would choose multiple short iterations over one long iteration any day. But the world has changed. Spurred by agile thinking, technical innovations in automated (acceptance) testing and automated deployment have made true continuous delivery not only possible, but more and more often, expected.

Reading the Scrum Guide in that context, one month seems awfully long. The Guide doesn’t actually set a minimum length for the sprint, but in practice I’ve never heard of sprints shorter than one week, because of the amount of overhead the Scrum ceremonies tend to introduce. It begs the question: when you can effortlessly release multiple times a day, why even have sprints at all?

Of course, the fact that some technical limitations have been removed doesn’t mean that there can’t be other reasons to use iterations of a fixed length. I will explore three possible reasons here.

Cadence and Predictability

Fixed-length iterations provide a certain cadence or rhythm that may be desirable. The same ceremonies always happen at the same time every X weeks, which gives a nice feeling of predictability to people both in and outside the team. Considering people’s agendas, it’s certainly practical for everybody involved if you don’t plan your sprint review at a different time every week.

Consider though that Scrum has multiple practices, but (aside from the daily stand-up) only one cadence. As stated in this excellent blog by Pawel Brodzinski:

Some of us got used to the fact that frequency of planning, releases and retrospectives is exactly the same, but when you think about this it is just an artificial thing introduced by Scrum. […] it is likely, that the ideal cycle of planning, releases and retrospectives isn’t exactly the same, so keeping cadences of all of these identical (and calling them iteration or timebox) is probably suboptimal.

In other words, you can have cadence without having fixed-length iterations. Also, I personally like to keep a cadence only for things that benefit from having a set cadence and which don’t flow naturally from the development process, like demos and retrospectives. I don’t see the benefit in a cadence for things that really should part of the daily workflow, like backlog refinement.

Motivation and Focus

Viewing each sprint as a mini project with a clear beginning and end can motivate the team and give the members a sense of accomplishment every time they successfully complete one. As requirements are not supposed to change during the sprints it allows the team to focus on the work at hand without being distracted. As a bonus it gives deadline-loving project managers a familiar buzz, and since the team voluntarily commits to that deadline there’s not much harm in that.

But as we all know this can easily backfire. Since people are generally optimists and tend to over-commit (and also because requirements will change), often they will not complete all the work within the time-box of the sprint, the deadline that worked as a carrot will start to be used as stick, the team will experience a sense of failure, and motivation will drop. To make matters worse this most often happens in new and inexperienced teams, where the effect can be the most devastating. Arguably, these teams don’t need deadlines, they need trust. That said, if this works as a motivator for your team it is a very strong argument to use sprints.

Metrics and Forecasting

To forecast the future of a project, a metric of story points per sprint (called velocity) is often used. Sprints of equal length make it really easy to reason about: if we have completed an average of twenty story points per sprints in the past, our forecast is that we will complete sixty more points in the next three sprints. This is arguably easier to work with than similar metrics like cycle time or throughput which can be used in a process with a continuous flow (no fixed iterations).

Measuring based on sprints also tends to raise a few questions though. Are analysis and backlog refinement activities part of the sprint and should they be planned? Are user acceptance tests part of the sprint? If they are, that makes planning a sprint quite impractical because of the increased dependence on outside factors. If they aren’t, our velocity is really only based on development productivity. When the bottlenecks of our process are outside the development team (as they often are), we still can’t forecast when a new feature will be released in production.

If you’ve found a way to deal with these questions and have found velocity to work for your team that’s great, but if you’re struggling with this, please consider that there are other ways to measure and forecast.

To summarize, the popularity of Scrum has made fixed-length iterations the default choice for agile development. If you take a step back though, it’s not immediately obvious why they are beneficial. There are legitimate reasons to choose sprints over continuous flow, but they all come with some caveats as well. Why do sprints work for your team? Have I missed any reasons? Please comment below.