In Scrum, the Product Owner is accountable for maximizing product value for the customer. That’s the focus of the entire Scrum framework, where value is delivered frequently and incrementally. But sometimes, the customer can jeopardize the value the Scrum Team is set to deliver. In some cases, the customer might have a work request that doesn’t warrant risking the value the Sprint Goal will deliver. In others, it makes sense to cancel the current Sprint to attend to an emergency. Sometimes, there’s a middle ground. So, how do the Product Owner and the Scrum Team navigate unexpected customer requests?
Value delivery in Sprints
First, let’s quickly review how we deliver value as a Scrum Team.
In Scrum, Developers work together to deliver value in Sprints. The purpose of each Sprint is to deliver a done increment of value. Each Sprint is one month or less — with the Sprint duration remaining consistent over time. Each Sprint starts with a Sprint Planning event where the Scrum Team creates a plan for work they will deliver in the upcoming Sprint.
During the Sprint Planning event, the Scrum Team selects the Product Backlog items they will complete, creates a plan for getting the work done, and establishes a goal describing the value they will deliver that Sprint. During the Sprint, the Developers meet daily to inspect their progress and adapt their plan for the next 24 hours. At the end of the Sprint, the Scrum Team reviews the Done increment with stakeholders at the Sprint Review, and then the Scrum Team meets to discuss how they can improve how they work together. The cadence of the Sprint is the heartbeat of Scrum, and it runs smoothly and consistently for high-performing teams.
But what happens if there is a customer emergency or unexpected, urgent request mid-Sprint? Does the Scrum Team ignore it until the next Sprint Planning event? No, Scrum does not require the team to ignore an emergency which is identified mid-Sprint. Instead, the Product Owner has several options. Let’s look at each one.
1. Postpone the work
The Product Owner can receive the customer’s request but may decide that the request is not high priority enough to interrupt the Sprint. While we might be motivated to please the customer and stakeholders, a skilled Product Owner understands that changes to the Sprint slow value delivery. Unless the request is urgent, the Product Owner may decide to add the work to the Product Backlog and wait for the team to select it at the next Sprint Planning event. Postponing the work doesn’t have to jeopardize our relationship with the customer when we have clear communication explaining the reason for not interrupting the Sprint with their request.
2. Add to current Sprint
The Product Owner may decide that the work is important enough to engage with the Developers to determine whether the team can add it to the current Sprint without putting the Sprint Goal at risk. This might involve negotiation between Developers and the Product Owner and could result in removing lower-priority work from the Sprint to accommodate the request.
3. Cancel the current Sprint
In some cases, the Product Owner may determine that the circumstances of the new work make the value of the current Sprint Goal obsolete. For example, suppose the Scrum Team is working on value for the BlackBerry device in the midst of the initial iPhone release. In that case, the Scrum Team might want to regroup to determine if their current work needs to change direction based on the unexpected situation in the marketplace. This kind of crisis happens rarely; I have only seen it once in my career.
Improve quality to reduce frequency of emergencies
Emergencies should be infrequent. If your product has frequent emergencies, discuss it in the Retrospective to find out ways to reduce the frequency of emergencies for your product. You may need to consider adding Product Backlog items to the Product Backlog aimed at improving the quality of the product, or updating your definition of Done to add additional testing. Other options may be to improve Refinement or conduct user interviews to determine the root cause of emergencies. Further discussion may be needed for the Scrum team to diagnose the problem and find the best path forward.
Conclusion
Every Sprint is an agreement. The Scrum Team agrees to deliver a valuable increment of Done functionality at least once per Sprint, and the organization agrees to limit interruptions for the Scrum Team. But sometimes interruptions are unavoidable. Sometimes there is an emergency that can’t wait.
The Scrum Team cannot use the Scrum framework as an excuse to ignore an emergency. Instead, the Product Owner should use their judgment to determine whether the request is important enough to bring to the Scrum Team. The Developers then need to use their judgment to decide whether or not they can pull the work into the Sprint without putting the Sprint Goal at risk.
For the worst emergencies, the Product Owner has the discretion to cancel the current Sprint so that the team can begin a new Sprint. We would only do this if the value provided by whatever the Scrum Team is working on has become obsolete in light of the urgent situation.
It is often said that Scrum is easy to understand but hard to master. That’s because we need the courage to make tough decisions and focus on the tough problems. Dealing with customer requests mid-Sprint can be tricky. Knowing which of the paths to follow that we’ve discussed here is the art behind the science of the Scrum framework.
Scrum Day
Want to engage with thought leaders about Scrum? Join us for Scrum Day USA in Madison, Wisconsin. We're bringing together the best speakers and thought leaders from around the world to give you the conference experience you've always wanted. Get your tickets today before early bird pricing ends on May 1!
