Choosing a Scrum Sprint Length – Shorter Beats Longer

How long should a Scrum Sprint be? A Scrum Sprint is a short period of time when the Scrum Team works, but there is no hard rule as to how long that should be – in this post, we cover the pros and cons of shorter and longer Sprints and how you can discover what works best for you.

Let’s start with the purpose of a Sprint: a fixed period of time for the Team to focus and develop a product with quality high enough that they could release it to the customer. A “good” Sprint Length, then, has to be long enough to produce results, but short enough to limit risk.

The Scrum Guide says that:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done,” useable, and potentially releasable Product Increment is created.

Scrum Sprints are limited to one calendar month. When a Sprint’s horizon is too long, the goal of what is being built may change, complexity will rise, and risk is higher – all of which contribute to increased costs and unpredictability. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. As well, they limit risk to one calendar month of cost.

The Scrum Guide leaves it up to the Team to decide what Sprint length works best for them. When you’re first starting out in Scrum, it’s reasonable to experiment to find out what that ideal length is, but there is one caveat: shorter Sprints (1-2 weeks) help reveal problems and impediments faster. Sometimes this is uncomfortable, which results in Teams favouring longer Sprints to avoid dealing with these problems. That isn’t a Scrum-like approach; Scrum is intended to bring the problems we have to the fore so they can be addressed.

Before getting into the pros and cons of different Sprint lengths, something that you should consider is Sprint Cancellation. The Product Owner may elect to cancel a Sprint when the original Sprint Goal becomes irrelevant. Sprint Cancellation should be rare – in fact, most teams should never experience this. However, if you find good cause to cancel a Sprint more than once, you should be considering what circumstances make this happen and fixing the underlying problem.

Why Shorter Sprints are More Effective

To understand why you ideally want to lean toward a shorter Sprint, let’s look at some pros and cons of different Sprint lengths. I’ve also included some tips to help you decide what might work best for your Team. Remember: this isn’t a substitute for getting the Team to make their own decision based on their understanding of Scrum.

Longer Sprints (3-4 weeks)

Important: If your Sprint is longer than one calendar month, you’re not doing Scrum anymore.

Pros

• It’s easier to start practicing Scrum with longer Sprints because Teams often assume it will be easier to deliver a valuable chunk of work and get it to “Done” in one month rather than two weeks.

Cons

• It is difficult to plan well for a three to four-week Sprint during Sprint Planning. This tends to lead to more “dark work” ^[1] being done.
• 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; e.g. new features or stories mid-Sprint.
• Fewer Sprint Retrospectives lead to fewer explicit opportunities to improve as a Team.
• Fewer Sprint Reviews give the Product Owner fewer opportunities to improve the product.
• Greater risk of Sprint Cancellation due to changes in the market or customer expectations.
• Greater risk of something going wrong that makes it impractical to deliver the original goal.
• Makes it easier to do “Mini-Waterfalls” within Scrum, i.e. Analysis -> Development -> Manual Test, with a certain number of days planned for each. This leads to the dark side and Scrum Theatre. Mini-Waterfalls also usually lead to the use of Hardening or Stabilization Sprints.
• Team and Organizational problems tend to be discovered and addressed more slowly.

Shorter Sprints (1-2 weeks)

Pros

• Since the Team has more, but shorter, retrospectives, they have more opportunities to make smaller changes. This also provides more opportunities to improve as a Team because….
• More frequent Sprint Reviews give the Product Owner more feedback and more frequent opportunities to update their thinking with respect to the Product Backlog. This should largely eliminate the need for the Product Owner to ever ask for a change (e.g. new Story) during an in-progress Sprint.
• Impediments and slowdowns are highlighted more quickly since the Team is expected to get 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 job of slicing stories or features into smaller chunks. This increases visibility and understanding of progress within a Sprint.

Cons

• It’s harder to get to a finished product at the end of a 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.
• People say that Sprint meetings are too much overhead for a one-week Sprint. However, Sprint meetings should scale linearly with the length of a Sprint. So, a one-week Sprint will have two hours of Sprint Planning; a two-week Sprint will have four hours, and so on.

Today, most Teams new to Scrum pick two-week Sprints.^[2] Some go as short as a week.

Note: On the rare occasion that I’ve seen Sprints shorter than one week, it seemed to reveal a much deeper dysfunction. In most cases, it’s unlikely to be the best choice.

Important Tips

• Once a Sprint has started, don’t change its duration (i.e. don’t extend)
  – The end of Sprint is not a deadline, but an opportunity to pause, reflect, learn and improve.
  – If there are problems either in delivering the committed items or delivering the intended quality, you’re better off pausing and learning from the problems than changing the Sprint duration.
• Consistency – Humans benefit from having some consistency, structure and predictability in their world. So, once the Sprint length is set, it’s usually best to stick with it. The Scrum Guide even notes: “Sprints have consistent durations throughout a development effort.”
• Experiment – As your team and organization evolve, what used to work might change. Run experiments – example: https://medium.com/akeneo-labs/experimenting-one-week-sprint-93dd04b42191  Note: I don’t recommend growing a single team to 15 people.
• 2-day Sprints? In an extreme case, Mishkin Berteig coached one team to use 2-day Sprints using the short Sprint to reveal greater dysfunction in the organization.
• To do well with shorter Sprints, Scrum Development Teams need to work on some skills:
  – Story Splitting – so that they divide the work into small manageable chunks
  – Agile Engineering Practices – to ensure that increment delivered is of high quality
  – Learning to put Quality Assurance at the beginning and not the end of their development process. Usually this requires learning Behavior-Driven Development, also known as Example Driven Development.

Choose the Scrum Sprint Length

We’ve reviewed the purpose of a Sprint, and some pros and cons of Long versus Short. So now how do you decide what length of time to use? Consider everything by asking questions of the Team to prompt discussion. Some examples:

–       How long are you comfortable with potentially creating the “wrong” thing? (i.e. what is your risk threshold?)

–       How often do you want to get feedback from the PO/customer?

Can you think of more good prompt questions? Please share in the comments.

Whatever Sprint Length you set, honour it as the Team’s choice.  Then review, experiment, and adapt until you find the “sweet spot” that works best for your Development Team.

Additional References

“The Sprint Length” by Sjoerd Nijland

“What is the optimal sprint length in Scrum?” by Matthias Orgler

5 November 2019: Updated for 2019 from 2013

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.