How long should your sprint be? Although the latest version of The Scrum Guide (version July 2013) says it should be time-boxed at “one month or less”, the most common length in practice seems to be two weeks.
The underlying rules for sprint lengths are:
- choose the length that is best for your situation (keeping in mind that the aim is to accomplish some releasable output within that time frame); and
- make their length consistent from one sprint to the next.
Shorter sprints are favourable for the following reasons:
- requirements may change: what was originally needed may no longer be the case, so a shorter sprint allows your business to alter direction if needed;
- release more frequently: each sprint should contain release-ready features so you are able to release more frequently;
- reduces waste and limits risk: if the worst happens (i.e. you waste the whole sprint working on something useless), at least you realise quickly;
- better collaboration: when sprints are short, stakeholders are happier to discuss a feature being split up into smaller parts and will also consider moving some or all of the requirement to a later sprint;
- keeps complexity in check: you need to be able to complete each item in the sprint backlog within the sprint, so a shorter sprint helps keep things simple;
- shorter meetings: if you’ve ever worked on a project where you were planning more than a month’s work, you will know that it’s no fun. Shorter the sprint, shorter the meeting (usually);
- regular opportunity to inspect and adapt: the shorter the sprint, the more regularly you can review your approach.
So why doesn’t everyone have one week sprints? It’s not quite that simple or easy. It’s a balancing act: you’re trying to find an equilibrium where you maximise the benefits but don’t paralyse the team.
Firstly, could you reduce the sprint length? For example, is it possible to release more frequently? Because, unless you can release at the end of each sprint, many of the benefits mentioned would be nullified or at least diluted. However, lots of teams would find the overhead to release more frequently unbearable. So what changes would you need to make? Would you need a different infrastructure? How could you bring in automated tests?
Secondly, consider what would happen if you did shorten the sprint length? How harmonious is the team? Will they, and the product owner and stakeholders, adapt to more frequent meetings (planning, retro, sprint review)? Although the sessions should be shorter, it is often perceived that they are in meetings more than before.
In summary, shorter sprints might be attractive, but don’t expect them to be successful without some thought and effort.
Have you already gone through the journey to increase the frequency of releases? We’d love to hear your story in the comments below.
Homepage image by Paula Patrocínio