Choosing a Sprint Length

Owned by Quesnel, Angelique (Unlicensed), created
Last updated: Jun 26, 2021
6 min read

A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals. 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.

When first starting in Scrum, it’s reasonable to experiment with Sprint length to find out what works best for your context at that moment in time. Choose a length that’s too long, and it will be hard to keep change out of the sprint. Choose a length that’s too short, and a team may struggle with completing significant work within the sprint or weaken their definition of done to do so.

Shorter Sprints (1-2 weeks) help reveal problems/impediments faster. Sometimes this is uncomfortable; and teams consider longer Sprints again to avoid dealing with these problems. This isn’t a Scrum-like approach; Scrum is intended to bring the problems we have to the fore. Sprints of 1-2 weeks are short, while those of 3-4 weeks in length are long. Common practice for software development is 2-weeks Sprints.

Longer Sprints (3-4 weeks)

Longer Sprints (3-4 weeks)

Pros

Cons

  • It’s easier to start doing Scrum with longer Sprints

  • Difficult to plan well for a 3-4 week Sprint during Sprint Planning.

    • This leads to more “Dark Work” being done which is any work that wasn’t intended to be done during the Sprint that is picked up and done without being surfaced to the team and placed on the board.

    • Related to dark work – new features and needs tend to crop up more often mid-Sprint.

    • The Product Owner will have a harder time not asking for change; i.e. new features or stories mid-Sprint.

    • Fewer Sprint Retrospectives lead to fewer explicit opportunities to improve.

    • Fewer Sprint Reviews give the Product Owner fewer opportunities to improve the product.

    • Makes it easier to do “Mini Waterfalls” within Scrum, i.e .Analysis ->

    • Development -> Manual Test, with a certain number of days planned for each.

    • Problems tend be discovered and addressed more slowly

    • Lack of focus

Shorter Sprints (1-2 weeks)

Pros

Cons

  • Since the team has more but shorter retrospectives they have more opportunities to try small changes. This also provides more opportunities to learn.

  • More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to change. This should largely eliminate the need for the Product Owner to ever ask for a change (i.e. new Story) in the current Sprint.

  • Impediments and Slowdowns are highlighted more quickly, since the team is expected to get the feature(s) to done by the end of every Sprint. This forces the team to come to terms with things that are slowing them down.

  • Shorter cycles make planning easier, which increases focus and reduces the amount of “dark work”.

  • Forces teams to do a better of job of slicing Stories or Features into smaller chunks. This increases visibility and gives the Product Owner better control over prioritization and de-prioritization.

  • It’s harder to get to a finished product at the end of one or two week cycle. Caveat this is true at first however most teams are able to get the hang of it after three to four Sprints.

  • Working in one week Sprints can be more stressful at first.

  • Overhead – people say that the Sprint Meetings are too much overhead for a one week Sprint. However sprint meetings scale linearly with the length of a Sprint. So a one week Sprint will have 2hrs of Sprint Planning, a two week Sprint have 4hrs and so on.

Reference Material

21 Tips on Choosing a Sprint Length 

  1. Don’t ever go longer than 4 weeks… if you do, by definition it’s not a Sprint anymore.

  2. Scrum is about fast feedback – shorter Sprints mean faster feedback.

  3. Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.

  4. High-performance teams need pressure to form – shorter Sprints provide pressure.

  5. Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.

  6. “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.

  7. If you have lots of interruptions that are disrupting your Sprint plans, shorten your Sprints to match the average frequency of interruptions… and then just put them on the backlog.

  8. 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.

  9. 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.

  10. Small failures are better than large failures, shorter Sprints help.

  11. 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.

  12. 2-Week-long Sprints are most common for IT and software product development.

  13. Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.

  14. 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.

  15. If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.

  16. Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.

  17. Experiment with extremely short Sprints to see what is possible: 1-day long, for example.

  18. 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.

  19. If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.

  20. 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.

  21. When a team is new, shorter Sprints help the team learn its capacity faster.

Tap on > to expand or collapse view.

The Scrum Team decides the Sprint length.  The time box for a Sprint should be 30 days or less. These are some variables to consider about Sprint length. The Scrum Team should consider how often market conditions change. They should consider how long they can wait for stakeholders to give feedback at the Sprint Review to inspect the Increment and adapt the Product Backlog, the risks to technology uncertainty, dependencies external teams may have, and the length of time they can stay focused.

Shorter Sprints such as 1 week Sprints tend to be more costly because of the additional overhead of the Scrum events. The consistency of the time box provides focus, and gives the Development Team a way to learn and improve on what is possible within a steady length of time. Varying Sprint lengths usually result in a loss of productivity as well.

The Development Team needs to learn how to deliver a "Done" Increment within the time-box, and to establish a consistent, predictable rhythm, or heartbeat of delivery. The fixed time-box helps with focus as well. There would be more longer term harm done. Most likely you would just end up extending the Sprint more than a few days, and the Development Team won't take time boxes seriously in the future. Soon time boxes for other Sprints and events won't matter either if you break the rules. The Scrum Team will have the opportunity to inspect what happened, and adapt next Sprint.

As Scrum Master, he or she should advise the Development Team that the time-box needs to be respected, and that the Sprint will not be extended per Scrum rules.  More importantly the Scrum Master should be teaching and coaching Scrum values of respect (the rules of Scrum), focus (the gift of the Sprint time-box, commitment (to do the right thing), courage, and openness. 

Sprint length can be inspected and adapted in the Sprint Retrospective, however, the Sprint is the heart beat of Scrum, so be careful not to throw it off very often. If there are multiple Scrum Teams working on the same product, it is often desirable to align the Sprints, to either have them all of the same start and end, or at the very least so that there is a regular cadence where both
team's Sprints end together.

For instance, if both teams are running 3 week Sprints, it might be acceptable for one team to choose to have 1 week Sprints, because there would still be alignment every 3 weeks, but if the team instead opted for 2 week Sprints, that alignment would only happen every 6 weeks, which might be problematic.

Essentially, while it is the decision of the Scrum Team, it is best to collaborate with the organization (including other Scrum Teams) to find a convenient solution.