What Is the Ideal Sprint Length in Scrum?
I could have spent our time together today to talk about all kinds of practices when it comes to determining the perfect sprint length for your Scrum team.
However, I’d prefer to offer an alternative perspective instead.
While fixed timeboxes are a hallmark of Scrum, there is something in the project management world that actually makes rigid sprint duration counterproductive.
What is it? The variation in how long tasks take to complete.
In both cases, whether you’re a team just starting to optimize your workflows or one with a well-established delivery system, the fact is that your completion times will inevitably vary.
The Dilemma of Fixed Sprint Timeboxes
In the most common scenario, sprints are typically two weeks long, a timeframe that many teams find effective. The problem comes from the fact that the timebox is fixed.
Not all tasks are created equal.
Some are straightforward and can be completed quickly, while others are complex and require more time. Their completion times will vary.
Additionally, external factors like extra work, defects, dependencies, bottlenecks, and blockers can further contribute to this variability.
Now, you might say, “Sonya, we’ll divide our tasks to fit the timebox,”. If that sounds like you, I encourage you to go back to your goals and reflect on this question: ‘When we break down our tasks, do we still solve our client’s problem? With this new item, would our customer still be able to give us feedback to ensure we’re on the right track?” If your answer is “no,” this means that your actions are driven by the wrong motivation.
Or, you might say, ‘When we can’t finish something in the current sprint, we carry it over to the next one.” But have you considered the impact? How much time in total does this work item spend in progress as it moves from sprint to sprint? How many similar cases do you currently have?
Go ahead and check your Cycle Time Scatterplot. And if it turns out that there are plenty of work items that go above the 14-day mark, this is a clear sign that your current sprint length does not suit your team.
Use the Cycle Time Scatterplot to track how much time your work items take to complete. Start your free 14day trial here (no CC required) →
So, what’s the alternative?
Shift your focus to a continuous flow of work.
As your team has the capacity, pull tasks from the backlog. Instead of trying to fit everything into a fixed timeframe, move your team’s attention to finishing what they’ve started. Embrace the inherent variability in your process and adapt to it.
When you try to shape your work to fit into a fixed timeframe, you’ll find yourself making decisions that don’t necessarily align with your goals. Be mindful of these decisions and question them. If following the rules by the book prevents you from achieving better business outcomes, it’s time to rethink your approach.
What Is the Optimal Sprint Length in Scrum?
Back to the main point, what’s the ideal sprint length? The perfect sprint length is no sprints.
From a flow perspective, fixed sprint timeboxes attempt to impose an artificial structure on work that naturally varies in complexity and duration. Ideally, your process should be fluid, allowing tasks to be completed when they are ready rather than when the calendar dictates.
Embrace the flow-based approach to allow for a more organic and efficient way of working, where tasks are finished at their own pace.
Here is my main message for you today, question established practices and adapt to the realities of your specific context.
While fixed sprint timeboxes have their merits, it’s crucial to recognize that variability is a natural part of the process.
If the ideal sprint length is no sprint at all, I encourage you to focus on managing your flow. That’s the ultimate approach to building better products faster. Isn’t that our main goal at the end of the day?
Alright my friend, I hope I gave you some food for thought. Whether you choose a fixed timebox or prefer the flow approach, I’d love to hear your thoughts. Send me a DM on LinkedIn, and let’s keep the conversation going.
I’ll be looking forward to seeing you again here, next Thursday, same time and place for more managerial goodness. Bye for now!
Meet the Author
Sonya Siderova is a passionate product manager and a driving force behind Nave, a Kanban analytics suite that helps teams improve their delivery speed through data-driven decision making. When she's not catering to her two little ones, you might find Sonya absorbed in a good heavyweight boxing match or behind a screen crafting a new blog post.