Determining The Right Length Of Your Sprint
The duration of your Sprint sets the cadence for everything else in Scrum; Events, releases, the work itself.
Therefore, determining the optimal Sprint duration for your team will make a difference. Sprints need to be short; no more than four weeks long in order to enable rapid feedback loops and timely production of increments.
However, they must be just long enough for the Team to achieve their Sprint Goal and deliver something of value which is one reason different durations work better for different teams and organizations.
So how do you find that sweet spot?
“Well, there’s a lot to that,” says Scrum Inc. Principal Consultant Dave Slaten. Luckily, Dave paired with Scrum Inc.’s Kendra West to create a four-step experiment to help you determine if changing your Sprint length would be a process improvement.
Why Would Teams Change Their Sprint Duration?
Kendra believes new Scrum Teams should start on one-week Sprints because it leads to more rapid planning cycles. Dave agrees, but for a slightly different reason. It's amazing how much work people get done in the week before they go on vacation, both in the office and at home. There's this artificial sense of urgency, this deadline to get things done.” That sense of urgency, can be harness and transformed into focus and productivity.
They both, however, have identified three common reasons Scrum Teams look to change their Sprint duration:
- Scrum Teams feel they are spending too much time in the Scrum events and activities.
- They cannot “finish” enough work within one week to get useful stakeholder feedback.
- They want to align with a company-wide cadence.
All of these can be valid reasons depending on the unique circumstances for each team.
The most important aspect of deciding to change your Sprint length is to understand your team’s motivations and take a data-driven approach to measure if the change had a positive impact.
Step 1: State Your Hypothesis
Why does the team think a two-week Sprint would be better? Whether it is one or more of the reasons noted above or something entirely different, a reasonable assumption of improvement should be in place before making a change. This isn’t always the case.
Dave says the most common reason Scrum Teams he’s worked with want to change their Sprint Length is to decrease the amount of time in events. That implicit hypothesis, he explains, is not necessarily true. “If you take an academic view of the Scrum Guide, your Sprint Review is timeboxed to an hour per week of Sprint. Your retrospective is timeboxed to 45 minutes per week of Sprint.”
The length of events is not a linear equation. A two-week Sprint does not necessarily mean your Events will be exactly twice as long. Better enforcement of timeboxes for Events would likely be a better solution in this scenario.
However, if your Scrum Team does have a hypothesis to test, you need to make sure you’re experiment accurately captures the pertinent data. Which leads us nicely to the next step in this data-driven experiment.
Step 2: Design Your Experiment
Based on your hypothesis, identify what data should be tracked to demonstrate measured improvement.
Take the aforementioned amount of time spent in Scrum events. In this scenario Kendra and Dave would pose the following basic questions:
- How much time do you spend in Scrum events now?
- How much time would need to be saved to consider the change impactful?
- How much time do you spend in Scrum events with the alternate cadence?
Kendra cautions that is not all. “Another thing you really want to pay attention to is your velocity,” she explains, “Your velocity should increase proportionately to the extra time that you have added to your Sprint.” And points, she says, can be deceiving. “Maybe you're completing more points, but it's still fewer points in total, or less value, that you would have completed in two one-week Sprints.”
Step 3: Collect The Data
Establish a set of measures for before and after each alternate Sprint length. Capturing the data consistently and accurately will take both effort and time.
Kendra advises you to plan for both.
“In order to run these experiments, you have to give yourself a little bit of capacity to do the actual work.” And, she adds, “If you're not taking the time to think about continuous improvement, build these experiments, and actually do them, you're not going to be able to see the impactful changes and you might be missing out on.”
Both Kendra and Dave stress the need to run these experiments for at least three Sprints in order to accurately comparison each alternative.
Step 4: Analyze The Results
See how the data stacks up against your hypothesis and also consider any unanticipated consequences.
For simplicity, let’s return to the common ‘longer Sprints would mean less time in meetings’ hypothesis. And, let’s say that the hypothetical Scrum Team running this experiment saved one hour of event time when moving from one-week to two-week Sprints:
- Were there unexpected consequences like difficulty in planning effectively or an increased number of interruptions occurring in the second week of the Sprint?
- What is the return on investment of any time saved? Does it lead to more planned backlog being completed or does team velocity actually decrease?
The analysis step is where the whole team needs to put on their thinking caps and consider a number of different angles. There will be subjective elements, so be prepared to discuss those openly and not ignore or dismiss them.
This may lead to iterating and repeating parts of the experiment but will ultimately help the team understand their processes in more detail.
The team should be the ultimate arbiters of choosing the best way to work together. Taking a data-driven approach will instill confidence and reduce the emotional elements of the process.
Additional Considerations:
Finally, Dave and Kendra have identified these additional considerations that should be weighed when considering if changing your Sprint duration is a process improvement:
- If you double your sprint length, your average velocity should also at least double.
- The trend in velocity should also be increasing
- Your planning accuracy should stay the same or get better
- You can measure this by comparing the “say/do” ratio of completing the specific items in the planned Sprint backlog by the end of the Sprint
- You can also measure this by comparing the number of blocked or unfinished backlog items. Your interrupt profile should stay the same or get better
- A longer sprint means less patience for others who need something unplanned from the team. Longer Sprint lengths mean less frequent opportunities for user and stakeholder feedback
- Less frequent feedback may result in more uncertainty and wasted effort in Sprint deliveries
This post is part of our ScrumCast series of conversations with thought leaders who have successfully helped transform organizations and empower teams and individuals. Each episode explores organizational Agility and Scrum patterns, tactics, and techniques that drive real-world success. Subscribe to our YouTube channel for the latest ScrumCast episodes.
English 
French 
Spanish