The topic of the 13th episode of my blog series on “20 Controversial Topics of Debate in Agile“ is whether it’s OK to add items to a Sprint in progress. The Scrum Guide does a decent job of laying out the conditions under which it’s acceptable to make changes to the Sprint Backlog within the iteration. It says:
“The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned.”
The Scrum Guide
During sprinting, the Scrum Guide also states that:
- No changes are made that would endanger the Sprint Goal
- Quality does not decrease
- Scope may be clarified and renegotiated with the Product Owner as more is learned
This tells me that it’s perfectly acceptable to add new things or make changes to a Sprint in progress if there is a good reason for it. That said, even if there’s a good reason, it still might not be a great idea.
It’s okay to add new items to the Sprint Backlog if…
All the work for the Sprint is done
Very rarely have I seen a Scum Team complete every item they planned for in Sprint Planning. That is obviously a good goal to have, but new things are generally discovered through the development process, and change is inevitable.
However, if you magically finish everything you had planned for, you should consult the Product Owner on the Product Backlog’s next priorities. Otherwise, if items aren’t yet ready for the Developers, Scrum Team members should take the lull as an opportunity to cross-train or learn new skills.
You plan for “unknown” work
In a quote from one of my husband’s favorite movies:
“Unexpected things are going to happen, and when they do, nobody tries to be a hero.”
Alexa Wood, Aliens vs. Predators
Things crop up when least expected. I always like to leave a bit of buffer in my team’s capacity so that if or when this happens, new items can be added to the Sprint Backlog with little to no impact on the Sprint Goal. The intentional allocation of this extra time is a preventive measure that minimizes the impact of any changes.
An unsolvable impediment exists
I know you have all been here before: you have a problem that blocks your team’s progress, but you can’t resolve the issue. This could be for a variety of reasons such as:
- Technical constraints
- Dependencies
- Supply-chain issues
- Legal issues
- Lack of resources with the necessary skills
- Unpaid technical debt
- Etc.
When you run into this situation (and you will), it’s often better to recognize that you have very little control over the issue and pivot to adjust. This may mean moving the blocked story back into the Product Backlog until you can resolve the impediment. When that happens, the next logical step is to pick up the next highest priority work in the Product Backlog (with agreement from the Product Owner, of course).
The changes won’t jeopardize the Sprint Goal
If adding or changing an item won’t negatively impact achieving the team’s Sprint Goal, and the team has the capacity to do it, then why not? Tip: If you are adding something new, try to find stories that support the goal.
If the changes aren’t made, it will impact the Sprint Goal
On the flip side, if it’s discovered that something is missing or there’s a change that needs to be made or the Sprint Goal will be endangered, then the team should adjust accordingly. This will likely cause some churn and loss of efficiency, but it’s better to make the changes that miss the goal.
An urgent Production issue arises
I’m quite sure you have experienced this, too. As the product team supporting your product, when something goes wrong, you are the ones who get called. You created the product; therefore (unless you’re lucky enough to have a separate support team), it’s your responsibility to fix it.
These things usually trump everything else. If you have a down production system, you no longer have a product. When this happens, be sure to provide full transparency. Most stakeholders will understand it if something like this happens that causes you to miss your Sprint Goal.
Changes have been negotiated with the Product Owner
As new information is learned, the team must negotiate with the Product Owner regardless of what it is. If the Developers feel strongly about something they think something needs adjusting, they are responsible for communicating the changes to the Product Owner before acting.
The Sprint Goal has been achieved
As the first item on this list, if you have achieved your Sprint Goal, you can safely take on more work. My only caveat on this is that it’s better to bring in items only if they, too, can be completed before the end of the current Sprint. This is one I debate with people often, so I’d love to hear your opinion in the comments below!
Drawbacks of allowing changes in the Sprint Backlog
On the flip side, it might not be a good idea to make changes to work that is already in progress if:
It will cause context switching
Every time you stop something and start something else, you are context-switching. When you do this, you lose efficiency. When change is introduced, this is what happens. Whether it’s changing something you’re already working on or adding something entirely new, there will be a loss of productivity.
Future stories may not be ready
While ideally, you will refine the Product Backlog several Sprints ahead of being pulled for development, we all know that this is the real world, and this isn’t always possible (especially if the Product Owner also has a “day job”).
I would caution against pulling in items that do not meet your Definition of Ready in this situation. If you do, there will probably be a lot of questions, and ultimately, rework. This is an expensive proposition, and it would be better to wait until the requirements are stable and suitable for development.
The changes could jeopardize the Sprint Goal
If the proposed changes jeopardize your team’s ability to achieve their Sprint Goal, then you probably shouldn’t allow it to happen. Only changes that are either urgent or in support of the Sprint Goal should be allowed.
Focus will be taken off the most valuable items
By allowing unchecked additions and subtractions to your Sprint Backlog, you will lose focus on what is truly the most valuable work. If the Product Owner has done a good job with prioritizing and ordering the Product Backlog, this might not be a huge deal, but if the Product Backlog isn’t in a good state, you could end up bringing in lower-value items.
Summing up…
Sometimes it’s acceptable to add new items or make changes to the Sprint Backlog, and sometimes it’s not (aka the standard consulting answer: “It depends”). If the circumstances call for making changes, make them. But if there’s risk involved and you might have to do rework, you might want to rethink it. And whatever you do, make sure the Product Owner is in the loop.
So, what do you think? Should you be able to add new stories or make changes to your Sprint Backlog during a Sprint? I would love to know what you think!
And, for more discussion and debate on this topic, check out this thread on Scrum.org.
Next up in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can Agile co-exist with Waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?