If you’re reading this post, you’re probably a member or stakeholder of a Scrum Team who’s about not to meet their sprint goal or complete their sprint backlog — and is right now considering whether to extend its active sprint.
I’ve been in this situation multiple times throughout my agile experience as both a member and stakeholder (agile leader and project sponsor) of Scrum Teams. In this post, I will share my best advice to you for dealing with this dilemma.
Can you extend a sprint in the Scrum framework? Is it agile to do so?
No, active sprints in the Scrum framework can’t be extended (and it’s not agile to do so). The sprint is a timebox of one month or less during which the team focuses on the sprint goal and works on items on the sprint backlog to create a “done,” usable, and potentially shippable product increment. If the team fails to meet the goal or deliver the increment, this is a learning opportunity they can address in the Sprint Retrospective.
Here’s another way to think about it. You use the hours on the clock and the calendar dates to keep track of time. Hours and dates are, essentially, timeboxes. How you plan your time and what you choose to do with it is entirely your choice.
You set a goal for yourself and plan to do ten things in 60 minutes to achieve it. If you fail, you don’t change the length of an hour to 90 minutes to say, “I did it!”. Instead, you treat your failure as a learning opportunity to make better plans and do things more smartly the next time.
A sprint is not that different. Like the hours on the clock and the calendar dates, the sprint is just a timebox. It’s separate from and agnostic to the sprint backlog.
Why It’s Not a Good Idea to Extend an Active Sprint
Extending an active sprint is rarely a good idea (I first wrote “never” but decided to change it to “rarely” and stay open-minded, even if I have yet to come to a situation that calls for it).
One way to look at agile and Scrum is as a mindset and framework that help you work in cycles so that, over time, you can achieve a sustainable pace.
These cycles are called “iterations” in agile and “sprints” in Scrum:
- The Scrum Guide advises us that the length of a sprint should be one month or less;
- The Agile Manifesto tells us to deliver software frequently, from a couple of weeks to a couple of months, with a shorter timescale preference.
Scrum Teams estimate effort using story points. Story points are a relative measure, based on Fibonacci numbers (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100), for the effort that’s required to deliver a feature or enhancement from a product backlog item (PBI) to a potentially shippable product increment (PSPI).
Delivery is measured in velocity, which equals the number of story points completed in a sprint. If our Scrum Team decides to work in two-week sprints and completes PBIs estimated at 11 story points by the end of the sprint, its velocity is 11 story points. Velocity will vary in the first 3-5 sprints until the team learns to work together and achieves a sustainable pace.
If your Scrum Team fails to meet the sprint goal or can’t deliver the entire sprint backlog, don’t extend the sprint. You will bend Scrum’s rules to fool yourself and your stakeholders that you are good at using the Scrum framework. Which will prevent your team from achieving a sustainable pace. What good will that do for your team (and for your organization)?
Instead, use your Sprint Retrospective to talk about what triggered you to think about extending the sprint in the first place. Then try to identify the root cause behind it and agree on action steps to weed it out. If you’re having trouble getting there, ask an Agile Coach for help.
Demonstrate the work done during the Sprint Review and have an open conversation between the Dev Team, Product Owner, and the stakeholders that she has invited about the lessons learned — and what that means for the roadmap, backlog, and delivery as it stands.
Why Scrum Teams Think About Extending Active Sprints
Individuals and teams experienced in agile and Scrum will not even think about extending an active sprint. This is simply one of the dilemmas that almost everyone goes through at the beginning of their agile journey — and one of the lessons they have to learn through hands-on experience.
It’s rare to see this idea coming from the Dev Team itself. Usually, it comes from the Product Owner or Scrum Master for one of three reasons:
- The Product Owner needs more experience to set realistic sprint goals, or the Dev Team needs more experience to estimate work items more accurately;
- A desire to demonstrate early success in adopting agile and using the Scrum framework to their stakeholders (to read: management);
- Poor planning by the Scrum Team that didn’t take into account a critical event or hard deadline in the organization;
- Pressure from their organization, management, or customers to deliver on an arbitrary deadline or keep a commitment on a plan.
In any case, this is not a failure of the Scrum framework. This is a failure of the team and/or stakeholders to use the Scrum framework to their benefit and the organization’s competitive advantage.
The most important thing is for everyone in the chain to understand the situation and address the root cause to improve their working agreements or ways of working, sometimes as early as the next sprint.
The second most important thing is to address failure with the right mindset. When a child learns to walk, it does it through trial and error. Simply said, it falls down time and time again until it knows how to keep a balance.
Adults and groups of adults often adopt an unconstructive mindset toward failure. When they fail, they usually try to bend reality by making things seem optimistic or cheating the system to simulate success. Neither of these ways for handling failure is helpful.
Whatever your team’s situation, the best thing to do is to keep the active sprint as-is not to break the integrity of your cycles for the wrong reason, let events take their course and delivery be what it is, address the problem and root causes in the Sprint Retrospective, and stay open to your stakeholders about the challenges you’ve faced, the lessons you’ve learned, and actions you’re taking at the Sprint Review.
We’re often tempted to blame others for our attitudes and behaviors. If the idea came from the Product Owner, she would have a harder time admitting to her team that she’s still learning how to how not to give in to pressure from stakeholders. So she will naturally look for excuses for why she is getting pressure from the outside.
If the idea came from the Scrum Master, that’s a sign they need to build a better understanding of agile and Scrum (by themselves or through coaching). Often, we take the concept of change and flexibility in agile — and use it to solve the wrong problems. Acknowledgment of this and introspection about what caused it will help.
Suppose the idea came from the Dev Team (or the Scrum Team as a whole). In that case, the team should have a conversation about agile and Scrum with a focus on the role of cyclicity and the importance for their engagement and for the sake of the product that they’re building, of learning how to achieve a sustainable pace.
When pressure comes from management, it’s often a sign that the conversation and collaboration between the Scrum Team and its external environment are not at their best. Scrum teams often label the ask for target/delivery dates and the need for predictability as “waterfall,” but that’s not true. It’s merely the need to synchronize the organization’s planning cycle with the team’s planning process.
When Should a Team Consider Changing the Sprint Length?
Changing the sprint length is a decision best taken by the Scrum Team, in the Scrum Retrospective, before starting the next sprint. This decision can be temporary (only for the next one or two sprints) or permanent (for every sprint from that moment on).
A change in sprint length can be useful when it’s done before starting the next sprint and for reasons that help the team respond to change or continuously improve as long as it’s done at the right time and for the right reasons (by which I mean motivations intrinsic to the team and proactive rather than reactive).
I’ve seen Scrum Teams decide to temporarily extend the duration of their sprints during the holiday season or in summer. Since most of the team members are out of the office (and so are its customers), it sometimes makes sense to work in longer cycles to respond to the team’s decreased capacity and the customers’ slowed demand.
I’ve also seen Scrum Teams decide to permanently shorten or lengthen their sprints because the length simply didn’t make sense to them. For example, a team with dependencies on other teams or technology vendors tends to work in longer cycles because these dependencies often take longer than a couple of working days to resolve. It doesn’t make sense to work in one-week cycles when half of the work ends up being blocked.
The Bottom Line
In Scrum, the sprint is a timebox. It has a start date and an end date, which are determined by the sprint length.
It’s seldom a good idea to extend an active sprint. This is usually a consideration of individuals and teams who have yet to gain agile experience and need a learning curve to discover the actual problems and solutions to the problem.
However, a team can decide whether to change the sprint length before starting a sprint. This can be a temporary decision for one or two sprints or a permanent one because the previous length proved ineffective.
Whatever your situation, complete your current sprint as-is and let events take their course. Then treat them as the learning opportunity that they are — and use that opportunity to improve your ways of working and achieve a sustainable pace faster.
