How long should a sprint be? Many, if not all, software development teams who are using the Scrum framework to implement Agile principles, will have asked this question. While sprints are limited to one month (4 weeks) under the Scrum framework, there’s no set length for a sprint. There are pros and cons of short sprints (1 week) and long sprints (3-4 weeks) as sprint length can impact the workflow and management of a team in various ways.
Common Practice
Most software development teams using sprints settle on two weeks for the length. Two weeks is a small enough increment of time that teams get most of the benefits of a shorter-length sprint, without too many of the negatives of a longer-length sprint.
Benefits of a two-week sprint:
- The work to be completed in the sprint can be planned out relatively well
- The estimates of task durations are reasonably accurate
- There’s a reasonable amount of work for developers to do
- The duration of the sprint is not so short that it becomes difficult to manage
Shorter Sprints
The shorter the sprint gets, the more ‘agile’ it becomes. However, although a two-week sprint provides benefits, even more benefits can be found when going down to a one-week sprint. In fact, a one-week sprint is recommended as the ideal length for a sprint.
Benefits of a shorter sprint:
- There are fewer interruptions; people are less likely to jam work in, because the next sprint is close enough for ‘urgent’ work to be done in a timely fashion.
- There’s less multitasking or work-in-progress, because there’s not more than a few options for people to choose from when they’re working
- The task duration estimates are more accurate because they’re timelier and they’re closer to what people are doing.
However, some aspects of planning and executing a sprint become a little more difficult to manage and maintain in shorter sprints. Although it’s true that the shorter the sprint, the more benefits you generally receive, some of the negative side effects that result from a shorter sprint may also be more pronounced.
Disadvantages of a shorter sprint:
- The team must have more frequent sprint planning meetings
- It becomes more difficult to manage handovers and completion of work.
- Team leaders and developers have to be a bit more ‘on top of things’ to manage any variations to tasks or task estimates.
- Short sprints can be difficult to maintain long term.
This combination of factors is probably why we haven’t yet heard of a business doing one-day sprints!
Longer Sprints
What about when teams use longer sprints?? Often teams choose a longer sprint length because they assume it’s easier to deliver a valuable chunk in say one month, than one week. The one-month sprint is sometimes chosen as a team starts to implement Scrum.
Are there benefits of a longer sprint?
Longer sprints appear desirable as they allow more time to develop something of value. There’s potentially more uninterrupted thinking time and less deadline pressure which could impeded on a developer’s ability to get in the zone.
However, the longer the sprint length, the more a team’s workflow is likely to be impacted by variation and task estimates blowing out. In situations where teams are doing one-month sprints, someone must plan and estimate an entire month’s worth of work at one time which can be a large management burden. With more work available to start, there is increased opportunity for developers to multi-task and have a lot of work-in-progress but not completing or delivering value.
Part of the issue is that the longer the deadline, the more the sprint execution resembles older project management techniques or Waterfall method.
Negatives of a longer sprint:
Task duration estimates become more difficult to make accurately
There are more and more interruptions because people can’t wait until the end of the sprint and start jamming ‘urgent’ work in
There are increased amounts of more unfinished, or paused, work-in-progress
There are more opportunities for multitasking which leads to increased pick-up-put-down time as developers must reengage with a task they’ve previously started.
The Impact of Multi-tasking and Work-in-Progress on Productivity
Multitasking and increasing work-in-progress both massively destroy the productivity of a team. Most people, particularly developers, know the value of being in the zone – and, because of that, they know how important it is to preserve that state. By multitasking, that “in the zone” state gets wrecked left, right, and centre.
Multitasking often occurs proportionately to the amount of work available to be started, or the amount of work-in-progress. The more work is started and put on hold to start something else, the more unfinished work begins to pile up. This unfinished work might never actually be finished, could become irrelevant, or just clog up people’s thinking in terms of “I still need to finish that.” This problem is a lot easier to spot when work is held in physical files.
In software, most work-in-progress is virtual, and because of that, sometimes the negatives of too much work-in-progress and multitasking can be forgotten. Remember, each time the developer comes back to a task they’ve previously put down, they must pick it up, re-engage with it and mentally think through, “What was this again? Why did I code this like that? Why did we need that feature again? What was the user story in this scenario?”
Summary
The longer a sprint lasts, the more opportunity there is for multi-tasking and increasing work-in-progress to occur. As you pare the sprint length back (ideally to one week), you decrease the amount of work people can choose from and reduce the opportunities for multitasking to occur and all the issues that come with that. A one-week sprint can be more difficult to manage and maintain; Shorter sprints require team leaders to stay ‘on top of things’ and the more frequent planning required creates more overhead. Most teams settle on a compromise of two weeks, but some of the potential benefits of sprints are left on the table by doing this.