It’s day 2 of a sprint. You’ve got 2 weeks of valuable work to do, and the team is off to a good start. Suddenly, an email comes in from your VP: Production is down. A key customer is upset. And it’s your team’s problem.
What do you do?
Strictly speaking, Scrum has two possible answers here:
- Put that fix at the top of the backlog. It’s clearly the most important thing to do. We’ll get to it in a couple of weeks.
- Cancel the sprint. Replan based on the new reality. Reschedule your events accordingly.
Neither of those feels like a good answer from a business perspective. Of course, we’re not gonna wait 2-4 weeks to get that production system back up. But canceling the sprint feels kind of excessive, almost punitive—“You want to change our sprint backlog? Fine, but we’re gonna burn it all down in the process.”
That said, we shouldn’t be too quick to dismiss the Scrum way out of hand. Those things are the way they are for a reason.
If we want to navigate this situation and others like it successfully, we need to understand both Scrum and our context deeply. And then we need to mindfully find a way forward that balances competing demands.
The Scrum Way
Why is Scrum so strict about not changing the sprint backlog mid-sprint? Focus. Frequent change to a team’s backlog kills their productivity and demoralizes the team—especially when change feels arbitrary. Protecting the focus of the team during a sprint allows them to get increments of work done. That’s motivating, provides a real measure of progress, and emerges important info about the problem and the solution.
At the same time, there are genuine emergencies in business. That production system really can’t wait 2-4 weeks to get back online.
So, we need to simultaneously protect the focus of the team as much as possible while allowing for some amount of genuine emergencies. In our Humanizing Work Show episode about this, we recommend an approach called the expedite lane. Very briefly, it works like this…
The Expedite Lane
When emergencies come up, treat them as emergencies. Pause the planned work as necessary to rush the emergency through. Let the lowest priority planned work fall off the bottom of the sprint. In your sprint review, look at what you expedited and what fell off the bottom of the backlog. Let this comparison change what you treat as emergencies. Commit to less work in the next sprint based on how much planned work you actually got done.
Watch, listen to, or read the transcript of that Humanizing Work Show episode to learn more, including visuals of how you might model this on a team’s Scrum board.
The key idea, though, isn’t our particular solution to this dilemma (though we’re rather fond of it). It’s the approach we used to find it. Understand why Scrum (or whatever existing process) is the way it is. Understand why the current situation is in conflict with that. Consider what the best reason for addressing that need is. Then look for ways to get both of the things you care about. In this case, focus for most things and responsiveness for genuine emergencies. The expedite lane gives us both these things by rushing emergencies through a team but making the cost of doing so visible to stakeholders.
Need help adopting an agile approach that fits your unique context? Let’s talk.
Last updated