How to determine the perfect sprint duration for every project phase
As an agile coach I get this question a lot! There is a simple and a more nuanced answer to this question. Let’s start with the simple one…
Start with 2 weeks
“Make it two weeks” is the standard recommendation of most agile coaches — and it’s certainly a starting point with which you can hardly go wrong. If you’re in a hurry or in doubt, make it two weeks.
Why? Well, two weeks seem to be the most common sprint length in practice, it is kind of the middle between the possible extremes and it gives you enough benefits without high cost. It’s also an easy enough advice for novice agile teams to understand and apply.
If you’re looking for a more nuanced answer that will benefit your project even more, read on…
Why do we “sprint” in the first place?
Sprinting gives us checkpoints to adjust our course
Before I can answer in detail, we need to create a common understanding of why we sprint in the first place.
A “sprint” is like a “mini project” inside your project. And in Scrum we divide our full project up into these equally long “mini projects” called sprints. Each sprint has its own planning, work phase and review (think “product launch”) & retrospective (think “lessons learned”). Every sprint has the same length and is never “extended” (think of a sprint like the 24 hours in a day — you wouldn’t add another hour simply because you didn’t get your work done).
But don’t we just plan once at the beginning of the project and review and learn once at the end of the project? Wouldn’t this improve our performance, because it reduces overhead? As you read this article, you most likely already know the answer: planning just once at the beginning of a project has many problems. But let’s state again, what the benefits of our multiple sprints in Scrum are:
- Planning is easier (and more precise), the shorter the planning horizon is.
- “Lessons learned” after each sprint can immediately improve the performance of the ongoing project.
- At the beginning of a project — when traditional planning happens — we have the least amount of information.
- Each review/retrospective/planning is a checkpoint to adjust our course towards the project’s goal.
- What the customer says initially is usually not what they really want or need in the end.
So sprints make us humble human beings again in that they don’t force us to predict the far future in minute detail without most of the information we would need for such a prediction. Sprints give us fixed checkpoints in time to adjust our course and plan the next stint in detail. All this helps agile teams to deliver more value.
What is your project’s goal?
Your project goal determines how long your sprints should be
To make use of these checkpoints that sprint reviews/retrospectives/plannings are, we need to be clear about the goal of our current project (or project phase):
-
If the goal is risk reduction, then I choose a shorter sprint length. This is true, for example if you’re not sure about what the customer wants (market risk) or about how to best use a new technology (technological risk). I would regularly advise a sprint length of 1 week in this ➔ 1 week sprints
-
If your goal is to develop a new product for which you already reduced basic risks (meaning you have a clear picture of what to build and how to build it), choose a medium sprint length. The most common example is early product development, where you already validated basic assumptions, but still need rapid feedback from your customers to sculpt the marketable product. I would recommend 2 weeks for your sprint length.➔ 2 week sprints
-
If your goal is to develop or improve a product that is already profitable (i.e. delivers value to customers in a proven way), go for the longer sprint length. The longest sensible sprint length is 1 month.➔ 4 week sprints
Everything shorter than 1 week creates too much overhead compared to the time you get to actually work on the product. And everything longer than 1 month deprives you of the much needed checkpoints. So the sprint length always has to be between 1 week and 1 months.
The formula for deducing your optimal sprint duration is this:
The more your project focuses on risk reduction, the shorter your sprints should be.
So for early prototyping and business model validation (think Lean Startup), most teams choose a sprint length of 1 week. This gives them plenty of checkpoints to correct the course — and these course corrections will be more drastic initially.
Once basic validation and risk reduction happened, most teams switch to 2-week sprints, because course corrections will not be so drastic anymore and it’s enough to do the “reality check” every two weeks.
When a product further stabilizes, some teams switch to the maximum sprint length of 4 weeks. Course corrections are even less drastic now and doing a review/retrospective/planning more often would not lead to more course corrections.
Project duration
How long your project runs can give you a clue towards your optimal sprint length
Another way to think about the same thing is: project duration.
Projects in an early prototyping or validation phase are seldomly longer than 6 months — more often they’re 2–3 months long. And having a long 1-month sprints in a short 2 months project would be almost like not being agile at all — just one checkpoint in the entire project won’t help much.➔ 1 week sprints
Projects for new products, for which basic risks have been reduced already, usually last about 6–12 months. For such a timespan, weekly checkpoints would be a little too much. You would most likely not adjust your course much after each sprint. So many teams choose a medium sprint length.➔ 2 week sprints
And if your project runs for significantly longer than one year (i.e. 2 or even 5 years), the same reasoning applies: monthly checkpoints are enough and you wouldn’t want to overwhelm your team with too many re-plannings, where in most cases not much would change.➔ 4 week sprints
Beyond the end of our Scrum nose
There is more in the agile world than Scrum and sprints…
What about sprints shorter than one week — or no sprints at all?
There are teams delivering value in shorter cycles: e.g. Google and Facebook perform continuous delivery and release an updated product multiple times per day. While continuous delivery can be done within the Scrum framework, some of these teams apply other agile frameworks like Kanban.
Also teams in incident management, operations or maintenance often don’t have the luxury of being able to plan the weeks ahead. Incidents, bugs, hacks or outages just appear without warning. So planning in the way we usually do in Scrum makes no sense for these projects.
Still these teams do schedule reviews and retrospectives to improve their performance and to plan “plannable” tasks (like infrastructure upgrades). Kanban is an often used framework for such projects.
I just wanted to widen your view for agile approaches outside of Scrum. Now back to the sprint length in Scrum…
Cheatsheet
Check out the cheat sheet summarizing this article
To summarize the reasoning that goes into picking the optimal sprint duration:
- More focus on risk reduction ➔ shorter sprints
- Shorter project duration ➔ shorter sprints
I also prepared a cheat sheet for you, summarizing the content of this article. It is available as a separate Medium article:
The optimal Sprint duration (Cheat Sheet)
I hope I could shed some light on the reasoning behind picking a sensible sprint length for your project. Keep in mind that these are no fixed rules, but merely guidelines — do not apply them blindly and always think first.
About me
I’m Matthias Orgler, an agile coach and Scrum trainer with more than a decade of practical experience in agile projects. I have worked in Silicon Valley, coached many international companies and today offer my experience in video courses 📺 and classroom trainings 👨🏫 from my European home in Germany. Feel free to contact me with questions — I always love to help and to make the world a better place by spreading the agile mindset.