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) | |
|---|---|
Pros | Cons |
|
|
Shorter Sprints (1-2 weeks) | |
Pros | Cons |
|
|
21 Tips on Choosing a Sprint Length
Don’t ever go longer than 4 weeks… if you do, by definition it’s not a Sprint anymore.
Scrum is about fast feedback – shorter Sprints mean faster feedback.
Scrum is about continuous improvement – shorter Sprints give a team more opportunities to improve.
High-performance teams need pressure to form – shorter Sprints provide pressure.
Each Sprint is, ideally, an independent project – longer Sprints may make it easier to get a potentially shippable product increment truly done every Sprint.
“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.
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.
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.
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.
Small failures are better than large failures, shorter Sprints help.
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.
2-Week-long Sprints are most common for IT and software product development.
Most Scrum trainers and coaches recommend Sprints to be 1 or 2 weeks long.
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.
If your team has trouble finishing all the work they plan for a Sprint, make the Sprint shorter.
Every Sprint should be the same length for a given team so don’t let your Sprints get longer just to “get everything done”.
Experiment with extremely short Sprints to see what is possible: 1-day long, for example.
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.
If you are working on a product, consider Sprints that allow you to release minor updates more frequently than your main competitors.
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.
When a team is new, shorter Sprints help the team learn its capacity faster.
Tap on > to expand or collapse view.
| Expand | ||
|---|---|---|
| ||
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. |
| Expand | ||
|---|---|---|
| ||
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. |
| Expand | ||
|---|---|---|
| ||
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 |
| Expand | ||
|---|---|---|
| ||
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. |