I am often asked, ‘How long should my Team’s Sprint be?’ and ‘Does the Sprint have to be a fixed-length?’ I find that it’s not enough to just say: ‘Don’t think too hard about it. If you’re using a reasonable environment and language like Java or dot-net, use a Sprint Length of two weeks. That seems to work for most Teams, but some are using one week or three weeks. Just see what works for you.’
Like so many topics in Scrum, Sprint Length is not so cut and dry.
Two Guidelines on Sprint Length
There are two guidelines to a Sprint’s length.
- The Sprint shouldn’t be changed after the Sprint starts.
- Sprints should be the same length.
I think the first bullet is straight-forward. It would be cheating to change the Sprint’s length after it starts. If the Team condoned changing the Sprint length, there would be a temptation to change a Story’s Doneness Agreement to allow for some internal scope creep. This is a bad thing – the correct thing to do is add another Story to the Backlog.
As for Sprints being the same length – that’s a little trickier. I’ve already advised that a Startup Sprint could be only a week long, so clearly I’m not totally adamant that all Sprints should be the same length. Since a Sprint is a feedback loop, the Team needs to take the Stakeholders into account. Having a fixed Sprint length gives the Stakeholders a constant ‘pulse beat’ of the Product Reviews, which is comforting and breeds familiarity. However, having different Sprint lengths for specialized Sprints, such as accommodating the Holiday Season, or another reason the Team and Stakeholders can agree on, doesn’t seem to be a terribly bad thing to me.
In both cases, don’t turn the sprint into a grind by forcing work to done. When we force work to done quality suffers and chaos is invited in. A Sprint is not about ‘busy work’ or control over individual performance, that leads to tyranny. Instead, use the Sprint’s increment to explore meaningful feedback so that we can better guide product development.
Is it Long Enough?
A Sprint must be long enough to actually complete Stories. That is, the Team needs to be able to get Stories Done. It’s a rule of Scrum that a Sprint should never be longer than one month. Generally speaking, the Sprint length should be approximately three times as long as it takes to Swarm on an average medium-size Story and get it Done. This seems to give enough ‘squishiness’ in the system to allow the Team to self-organize to get work Done. My experience is that a Story takes about 2-3 calendar days for a typical Team that is Swarming, so a reasonable Sprint length is two weeks. However, environments are different; some are easier (or harder) to work in than others. I expect a Team’s Sprint lengths to vary widely based on differences in the environment.
Is it Short Enough?
The Sprint length should be short enough so that the requirements churn is slower than the Sprint length can accommodate. That is, if the Sprint length is two weeks, then the Team is hoping that the changes in requirements happen slower than every two weeks. Meaning, the Stakeholders can wait until the end of the Sprint to see their ‘new stuff’ Done.
In today’s environment, it is typical that the requirements churn is too fast for the Sprint. There are bugs to fix in other systems the Team is maintainin
g, there are emergencies throughout the Organization to fix, and the Stakeholders are almost constantly changing their minds about what is important. These are all reasons for the Team to shorten the Sprint length or shorten the planning cycle.
Stuff happens, and Teams develop methods for managing the fact that requirements need to be changed more often than once a Sprint.
Be Open to Re-Planning the Sprint
Sometimes a Team’s Sprint length is just too long for their Agreements to survive; the requirements churn is higher than the Sprint length can sustain. It is tempting to make shorter Sprints, but maybe that can’t be done because either the Stakeholders can’t handle more frequent reviews, or because the Team can’t develop product any faster.
What does the Team do?
Scrum is nothing if not adaptive. In fact, if the Team is not adapting to meet its realities, it’s not doing Scrum. So, adapt… the Team could just have Sprint Planning sessions more often – perhaps once a week.
For example, say the Team has a two-week Sprint, from Monday to Friday two weeks later. Then the Team could plan every Monday, not just every other Monday. The first Monday the Team would fill its Sprint to 80% capacity or so, and the second Monday the Team Members would ask themselves the question, ‘What do we add now?’
I find that many Teams have spontaneously moved to this system, so it is a known pattern that is very successful. It should be part of a ScrumMaster’s toolbox to use with their Scrum Teams.
Looking for more Scrum tools to be
an effective Scrum Team?
We’ve got training for that.
As Always, Stay Agile.