21 Tips for Choosing a Sprint Length

Many teams that I work with choose their Sprint length without too much thought.  Often enough, that’s okay and it works out.  But, in some cases, it helps to think clearly and deeply about what length of Sprint to choose.

My advice is almost always to have shorter Sprints not longer ones. The idea is that the Sprint length is a way of putting pressure on the organization to improve processes, skills, tools, etc. to enable faster delivery. Short Sprints are one of the main reasons organizations start adopting automated testing, DevOps and Cloud – all of which are very good! The “Definition of Ready”, rolling wave Sprints, dual-mode hybrid and other are not a very good ways to fix this; they simply push the problem to other people outside the Sprint. Instead, the organization should work to encourage cross-functional Scrum teams with no dependencies outside the team. This is tough.

Here are 21 tips on choosing a Sprint length.

Reasons for a Shorter Sprint Length

1. Scrum is about fast feedback – shorter Sprints mean faster feedback from the marketplace.
2. Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
3. High-performance teams need pressure to form – shorter Sprints provide pressure.
4. If you have lots of interruptions that are disrupting your Sprint plans, shorten your Sprints. Match the average frequency of interruptions… and then just put them on the backlog.
5. If you feel like you team starts out by working at a leisurely pace at the start of a Sprint and then “cramming” at the end of the Sprint, then shorter Sprints will force the team to work at a more even pace.
6. Small failures are better than large failures, shorter Sprints help.  Which is better: “we spent four weeks building the wrong things” OR “we spent one week building the wrong things”?
7. If you are using Agile Engineering practices such as TDD, you should probably be able to do Sprints that are 1 week in length or less.
8. Teams go through the stages of team development (forming, storming, norming and performing) in fewer Sprints if the Sprints are shorter.  E.g. 5 Sprints if they’re 1 week long, but 20 Sprints if they’re 4 weeks long.
9. If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.  Shorter Sprints are easier to estimate!  (This is counter-intuitive, but works like magic!)
10. Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
11. If you are doing a project with a fixed release date/end date, then make sure you have at least 6 Sprints to allow for sufficient feedback cycles.  More is generally better which means shorter Sprint lengths.
12. If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.  (Of course, you can release even more frequently than your Sprints too…)
13. When a team is new, shorter Sprints help the team learn its capacity (also known as velocity) faster.

Reasons for a Longer Sprint Length

1. Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
2. “False” Sprints such as “Sprint 0” or “Release Sprints” may feel necessary if your Sprint length is too short – try to avoid the need for false Sprints.
3. Sprints need to be long enough that Sprint Planning, Review and Retrospective can be meaningful.  A 1-day Sprint would allow a maximum of 24 minutes for Sprint Planning, 12 minutes for Review and Retrospective each.

Other Sprint Length Considerations

1. Don’t ever go longer than 4 weeks (one month)… if you do, by definition it’s not a Sprint anymore.  The Scrum Guide is unambiguous on this requirement.
2. Don’t lengthen your Sprint to fit the “size” of your Product Backlog Items… instead, get better at doing “splitting” to make the items smaller.
3. 2-Week-long Sprints are most common for IT and software product development.
4. Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.  Sprints should be a dependable rhythm for the team.
5. Most Scrum trainers and coaches recommend 1 or 2 weeks for Sprint length.

Some Commentary

Regarding #8 in the reasons for making shorter Sprints… the wording is deliberate; the longer the Sprint, the more Sprints it takes for the team to go through the stages of development. Shorter Sprints put pressure on the team to gel faster. Longer Sprints allow teams to be more relaxed about their team dynamics. Therefore, to convert the statement to weeks, I would write: E.g. 5 weeks if they’re 1 week long, but 80 weeks if they’re 4 weeks long (4 weeks/Sprint x 20 Sprints).

Regarding #9 in the reasons for making shorter sprints… This is actually quite simple: if a team is having trouble finishing its work, it is often because the team cannot predict the future. This is natural and is often a consequence of the “Horizon of Predictability“. Doing a shorter Sprint allows the team to have a greater level of certainty about their work and improves the chances that they will predict / forecast / estimate accurately.  It means a bit more work for the Product Owner and the team to do Product Backlog Refinement, but that tradeoff is often worth it.

Some Agile teams release multiple times within their Sprint.  If you are interested in learning how to do that, give your team the Team Kanban Practitioner training and the Agile Software Developer training on-site.

Author’s Note: this is one of those articles where I thought of the title first and then worked to make the article meet the promise of the title.  It was tough to think of 21 different ways to look at Sprint length.  If you have any suggestions for items to add, please let me know in the comments (and feel free to link to articles you have written on the topic). – Mishkin.

If you find this useful, please consider contributing with our
“Value for Value” model.