How to Choose the Right Sprint Duration
Have you ever heard of - or experienced - these scenarios?
Not delivering on time? That's because the sprint is too short, there is no time to work!
We are not taking action after our retrospectives? It's because the sprint is too long, too much time between retrospectives!
We spend all our time in meetings! That's because the sprint is too short, so we keep going and repeating the same meetings!
During my years as an Agile Coach, I noticed that sprint duration regularly came up as an easy target for teams seeking to shift responsibility away from the problems they encounter.
So many times, teams have expressed doubts or frustration to me about the duration of their sprints. Yet these teams had iterations of varying lengths. Sometimes very short, sometimes longer. And yet, the duration of their sprints seemed to crystallize a recurring discomfort.
Often, the pace of their sprints was imposed on them by management, which sought to harmonize the delivery pace between different teams. This is especially true in a SAFe context, but we will come back to this point later. The problem is that this top-down decision can provoke a real outcry, and then become a real barrier to the adoption of good Agile practices.
When you think about it, every team experiences its own unique reality. With its own pace, goals, and constraints. Right?
So, let's get down to business. How can you determine the right duration for your sprint? In this article, I'll share some coaching tips that I've tried and tested with my teams. Let's take a look at them now so you can handle this type of situation.
In this article, we'll cover the following topics:
What is a Sprint? What is its ideal duration?
To start off on the right foot, let's review what a sprint is and how it can be useful in teams' daily work. The Scrum guide introduces the concept of a sprint as follows:
"Sprints are fixed-length events, lasting one month or less, to create consistency. A new Sprint begins immediately after the previous one ends."
- Ken Schwaber & Jeff Sutherland, Scrum Guide
The Scrum guide continues with this:
"Sprints enable predictability by ensuring that progress toward the Product Goal is reviewed and adjusted at least once per calendar month. When a Sprint's horizon is too distant, the Sprint Goal may no longer be appropriate, complexity increases, and with it, risk. Shorter Sprints shorten the learning cycle, thereby limiting the risks associated with costs and effort. Each Sprint can be considered a short project."
In SAFe, the definition is essentially the same. The only difference is that a Sprint is called an Iteration:
"Iterations are the basic building blocks of Agile development. Each iteration has a fixed standard duration during which Agile teams deliver incremental value in the form of functional and tested software and systems."
And what about the ideal duration of an iteration?
Here is what Scaled Agile provides us with:
“The recommended iteration length is two weeks. However, a length of one to four weeks is acceptable, depending on the business context.”
Scrum frameworks such as SAFe agree on recommending short development periods of one month or less. In both cases, there is mention of flexibility to adapt the duration to the team's context.
Note that by "learning cycle," the Scrum guide emphasizes the importance of the feedback loop inherent in each sprint. By meeting with your end user at the end of each sprint, you can gather the feedback you need to improve your product continuously. The same applies to your retrospectives, which are designed to facilitate team discussions and help the team improve.
After reviewing the theoretical aspects, let's dive into practice and look at the issues that teams frequently encounter when managing sprints.
The main objections surrounding sprint management
Here are the three objections I have heard most often during my years as an Agile Coach. No doubt you will recognize yourself in at least one of them ;)
Friction #1: We spend all our time in meetings!
Who hasn't heard or thought this before? Here, we must first identify whether the problem is (1) the frequency of meetings, (2) their duration, or (3) their relevance in the eyes of members.
Duration and frequency are closely linked. The longer the sprint, the longer the meetings. Generally speaking, I have noticed that most teams follow a rule of thumb of one hour per meeting per sprint week (1 hour for a one-week sprint, 2 hours for a two-week sprint, etc.). This rule therefore applies to your planning, reviews, refinements, and retrospectives.
To illustrate this rule in concrete terms, let's take the example of Sprint planning, based on the suggestions from the Scrum guide.
"Sprint Planning is limited to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is generally shorter."
- Ken Schwaber & Jeff Sutherland, Scrum Guide
Extending the sprint therefore does not really solve the problem of time spent in meetings. Rather than two hours every two weeks, a planning session will last, for example, three hours every three weeks.
💡 Coach's tip: As a team, question the relevance of your meetings by asking yourselves whether everyone's time is well spent. Beyond your retrospectives, you can extend this reflex to ad hoc meetings organized by external team members, commonly referred to as "Sync; 1-1; debrief; Update; etc..."
Often, these meetings are not sufficiently prepared, lack relevance, and team members feel obligated to attend. They can even be recurring and therefore detrimental to a busy schedule!
For example, at the end of a retrospective, ROTI is particularly effective for gauging your team's reaction to the meeting you have just had.
Friction #2: We're always chasing deadlines and never finish our deliverables!
Before looking at solutions, we must first identify why the team is not delivering the expected level of value at the end of its sprint. Often, the breakdown of stories is superficial and quickly done during the planning meeting - either due to lack of time or lack of expertise. This results in stories that are too large and with unknown variables that will inevitably delay delivery.
💡 Coach's tip: If your team regularly faces commitments that exceed its actual execution capacity, reducing or increasing your sprint duration will only add to the pressure. In this case, I suggest you go back to basics and review your DoR (Definition of Ready) and DoD (Definition of Done). To make your life easier, you can suggest that the team hold a refinement meeting, which will allow you to rework the stories for the next sprint before your Sprint Planning.
You could even establish your Velocity, as long as it is used to help you and does not become a vanity metric (a performance statistic that looks impressive at first glance but does not translate into concrete results in the pursuit of objectives).
Friction #3: No sooner has the sprint ended than we have to start again!
I understand this frustration. Agility is a marathon. So you have to find the right pace, as mentioned in the previous point. Once again, the length of the sprint provides little answer to this problem.
💡 Coach's tip: With your Product Owner's approval, suggest that team members work on their tasks in different ways. For example, organizing a hackathon allows members to break up the monotony of sprints. Note that SAFe suggests an innovation iteration per Planning Interval (2 weeks per quarter, for example).
How to decide on the right sprint duration
The team knows its own context best. Rather than a top-down approach where management decides the sprint duration, we would like the team to take responsibility and opt for a bottom-up approach where it decides for itself how to operate. It experiments, takes action, and adapts to the results. In other words, it is self-organized.
This trial-and-error process, supported by a culture of trust and transparency, allows you to find a sustainable and lasting pace, rather than applying a universal rule that does not take into account your team's context. The result is therefore more likely to be a success!
If, after consulting with your team, you decide that the duration of your sprint is the underlying problem that needs to be addressed, keep in mind that this change is not insignificant. Before making a decision, remember that there may be side effects.
If you lengthen your sprints, you lengthen your learning cycles.
The feedback loop with your client will be longer. If you wait for your sprint reviews before presenting your progress to your stakeholders, you are delaying the feedback process. By extension, you are exposing yourself to more risks... and therefore more unforeseen events.
You will reduce opportunities to look back and celebrate successes or take action on areas for improvement.
2-week sprints = 26 retrospectives per year
3-week sprints = 17 retrospectives per year
4-week sprints = 13 retrospectives per year
💡 Coach's tip: regardless of your sprint pace or even your framework (Scrum, SAFe, Kanban, etc.), don't hesitate to present your progress and value increments to your customers as early as possible. This will reduce the duration of your feedback loop. The same applies to problem-solving within the team, where you shouldn't wait for the retrospective to communicate.
If you shorten your sprints, you expose yourself to superficial feedback.
Feedback received too frequently can become superficial. Not enough time passes for sufficient learning to take place. This can give the illusion of rapid continuous improvement, but without real depth or consolidation of learning.
Alignment between teams can become a real challenge with short sprints. This is particularly true in a SAFe context, where PO and Team Coach synchronizations are added to other meetings.
💡 Coach's tip: Make sure you have stories ready that are small enough and properly managed from a risk perspective. The shorter your sprint, the less flexibility you will have.
What if the problem lies in the very concept of Sprints?
Some teams are better suited to the Kanban approach, which operates on a continuous flow rather than fixed cycles.
Source: Unichrone
Support teams for example handle customer requests on a daily basis. These requests cannot be anticipated and therefore cannot be planned for a future sprint. A continuous flow seems much more appropriate. Prioritization and delivery are continuous, and the pace adjusts naturally to the team's capacity rather than being planned in advance.
This approach promotes visualization of work in progress, limits multitasking (WIP limit), and highlights bottlenecks. It also enables smoother continuous improvement, as the team inspects and adapts its flow continuously, rather than at the end of a sprint.
For some teams, switching to a continuous flow can be a real liberation: less time pressure, more flexibility, and a constant focus on the value delivered rather than on completing a sprint. Food for thought...
Equip yourself well to get the most out of your feedback loop
Earlier in this article, I mentioned the importance of conducting your initial team assessment before making any decisions about changing the sprint duration.
Easy to say, but also easy to do thanks to Neatro. In fact, I recommend launching Neatro's Team Radar. This feature will allow you to build a comprehensive picture of your team by collecting asynchronous (and potentially anonymous) feedback on key aspects such as your team processes, collaboration, and velocity. This will give your team the freedom to take the time to express their views on both positive and negative aspects of their daily work.
Once you have gathered this feedback, you will be able to identify the team's strengths and weaknesses.
It will then be time for you to move on to the next step by dedicating a comprehensive review to the theme(s) you want to reinforce, using an activity that will allow you to think outside the box.
The Value bricks, Hopes & Concerns, the Pros and Cons, and the Star Wars Futurespective seem particularly well suited to the situation. The results of the Team Radar will naturally fuel your conversations and help you develop an action plan tailored to your challenges.
You can also get inspiration from other templates available in Neatro.
One last piece of advice...
There is no universal sprint duration, only the one that best suits your own team context. So encourage experimentation and, above all, value delivery, continuous learning and team cohesion. Be curious, and don't hesitate to think outside the box at your company by exploring a Kanban approach, for example.
Speaking of continuous learning, Neatro has been making my life easier for several years now, helping me support my teams and generate meaningful discussions. Whether it's about our sprints, their duration, or any other topic, I always have an activity tailored to the conversation I want to have with team members.
If you want to learn more, feel free to check out the Neatro retrospective experience. Launch a Neatro demo presentation here.
And if you'd rather get started right away, start using Neatro for free here.