Determining Sprint Length

There is no one-size-fits-all, magic bullet for determining a sprint length that works well for every team. Originally, Scrum called for one-month sprints, but nowadays many teams have been successful with two-week or even one-week sprints.

Choosing the right sprint length is about determining an appropriate stimulus-to-response cycle. In a sprint, the initial stimulus is the customer setting the priority of the stories. The response is the team building working software. The building of the working software is in turn a stimulus to the customer. The customer’s response is feedback. The more instantaneous that feedback, the higher the likelihood that what is delivered in the end is what the customers really wanted, which is not necessarily what the customer originally asked for. This stimulus-response cycle continues until the project ends.

Key Factors to Consider

When trying to determine the appropriate stimulus-to-response time for your project, consider following criteria:

• The expected duration of the project
• Customers/stakeholders
  • How often can they provide feedback and guidance
  • Scrum familiarity
  • The cultural barriers existing in the company or with the stakeholder/customer group
  • Environmental factors
• The Scrum team
  • Scrum experience
  • Technical capabilities (such as automated acceptance testing, TDD, automated releases, etc.)
  • Ability to decompose work

These elements play a critical part when any team is trying to determine whether its sprints should be one, two, three, or four weeks. Let’s look at each element in more detail.

Project Duration

Sprint lengths should be chosen in relation to project duration; however, they should never be longer than four weeks. Consider a three-month project. If it has four-week sprints, the stakeholders will only get to participate in two demos before the project is released. This is not enough feedback to mitigate the risks. Shorter sprint lengths are a necessity.

What about a year-long project? Assuming four-week sprints break approximately monthly, that project would offer 11 opportunities (plus the final release) for stakeholders to see the developing product. Four-week sprints are a realistic option, depending on the other factors involved.

Customer/Stakeholder Group

When working to determine sprint length with your customer, it is important to factor in three things.

• Customer group
• Company culture
• Customer environment

Look at the customer group first. It’s crucial to balance the team’s needs with the needs of your customer. Having a one-week sprint might solve some team problems but could put too much stress on the team’s relationship with the customer.

Next, examine the customer’s company culture. Is working with a Scrum team new to the company and its culture? Is it perhaps being tested in a pilot group? If so, consider that short sprints may give a false impression that Scrum teams put undue pressure on the customer.

The environment in which the customer conducts business can also affect the project. Environmental factors (such as regulatory issues) are often overlooked but, from my experience, often affect what the team can deliver and when. If your team has a large number of regulatory issues to contend with, you will probably want to choose sprint lengths of at least two weeks (three or four may be ideal), because of the amount of compliance assessment and auditing that will need to occur before any software can truly be considered shippable.

Scrum Team

The Scrum team itself is a factor in determining sprint length. Considerations include the following:

• Team experience with Scrum
• Team engineering capabilities (e. g., test driven development, continuous integration, pair programming, etc.)
• Team ability to decompose work

As a rule, an inexperienced Scrum team should stick with two-or four-week sprints as a one-week sprint is much more advanced and better suited for established teams that have a good working relationship, excellent engineering practices, and be adept and confident in decomposing work (or want to get better through a trial-by-fire).

Determining sprint length does not need to be a daunting task, but it does require thoughtful consideration. The right sprint length balances our craving for customer feedback and input with our ability to deliver and our customer’s ability to respond.

For more information on how to determine the length of your sprint, please read Chapter 6 in The Scrum Field Guide: Agile Advice for Your First Year and Beyond