Choosing a Sprint Length – Shorter Trumps Longer

The Agile Atlas (the Scrum Alliance’s Guide to Scrum), provides little advice when choosing your Sprint length, saying only: “A Sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals.”

It leaves it up the team to decide what will work best for them. These notes are intended to help navigate the tradeoffs involved.

When you’re first starting out in Scrum, it’s reasonable to experiment with Sprint length to find out what works best for your context at that moment in time. There is one caveat: shorter Sprints (one to two 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 one or two weeks are short, while those of three to four weeks in length are long.

Longer Sprints (3-4 weeks)

Pros

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

Cons

• Difficult to plan well for a three to four week Sprint during Sprint Planning. This leads 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; 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

• Since the team has more but shorter retrospectives they have more opportunities to try smaller 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 deprioritization.

Cons

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

Today most teams that are new Scrum pick two weeks Sprints. Some go as short as a week.