Often, teams have a sense some of the ‘emergencies’ aren’t really emergencies but don’t feel like they have the power to push back. The expedite lane approach is an example of the advice we give all the time: ‘If you can’t fix it, make it more visible.’
In this episode, Richard answers the question: “Our team is trying to use Scrum, but we get a lot of interruptions, a lot of work that pops up mid-sprint. How do we handle that kind of thing well?” He explains how to borrow a couple of concepts from Kanban to accommodate emergent work on a Scrum team in a healthy way.
Related Content
PO Board Overview
Effective Sprint Reviews
The Humanizing Work Guide to Splitting User Stories
Learn More
Certified Scrum Product Owner (CSPO) Training
Certified ScrumMaster (CSM) Training
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!
If you have a question you’ve been pondering, email us at mailbag@humanizingwork.com, and we’ll see if we’ve got a good answer for you.`
Before we jump into today’s episode, just a quick reminder to rate and review the HW Show in your podcast app, or if you’re watching this on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. Your help spreading the word is super meaningful to us!
This week’s question is one we get all the time. The question is: “Our team is trying to use Scrum, but we get a lot of interruptions, a lot of work that pops up mid-sprint. How do we handle that kind of thing well?”
This is a common question because it’s a common challenge. Whether it’s stakeholders who have an urgent need or production issues that a software team needs to address, many Scrum teams have a mix of planned work that fits nicely into Sprints, and unplanned work that doesn’t.
The kind of naive, official Scrum Guide answer is: Anything that comes up mid-sprint goes to the top of the product backlog for the next sprint. And if you really, really must get it done now, you need to cancel the Sprint and replan.
Before we laugh off that answer as unrealistic and impractical, we should note that there is something to it. Many teams experience constantly changing priorities not because they have genuine emergencies but just because they’re responding to other people’s whims and not working in a strategic way to maximize value. So, protecting the Sprint Backlog and giving the team a couple weeks of focus before introducing change can be a good way to move from constant churn to actually getting stuff done.
Because of that, the first question I ask when a team brings up the challenge of mid-sprint changes is, “Did the work genuinely emerge mid-sprint, or did somebody just decide they wanted a thing right now?” If it’s the latter, we’re better off looking at how we do Product Ownership rather than changing how the team organizes their work during a Sprint.
Now, for the rest of this episode, I’m going to assume I’m talking to a team that really does have emergencies they have to handle mid-sprint. The most common case is the team that’s building a product and also providing some kind of production support for it part-time. This team would prefer to follow their plan for the Sprint and get some features built, but they also have to deal with issues that come up in production, and some of those issues are genuinely urgent and can’t wait until the next Sprint. The extreme case is: we’ve just started a two week Sprint, and the production system totally goes down. Of course, we can’t say, “Oh,no problem, just put it on the top of the backlog, and we’ll have the system back up by the time the next Sprint ends in 4 weeks.” Getting that system back up is top priority right now.
To handle this situation while preserving some of that focus that Scrum is so good for, we need to add a little bit of Kanban into our Scrum. By the way, combining Kanban and Scrum is a thing that we do all the time. Check out our Product Owner Board episode to see how we use a Kanban system to structure the Product Backlog. We’ll link to that in the show notes.
For this situation, we’re going to introduce two concepts from Kanban: classes of service and work in progress, or WIP limits.
First, classes of service. A class of service is just a policy for how certain things are handled. The standard class of service in Scrum is, essentially, once something gets to the top of the Product Backlog, it’ll get done by the end of the next Sprint. But as we’ve already noted, that class of service isn’t good enough for true emergencies. We need to introduce what we’ll call an expedite class of service. When a work item gets the expedite class of service, it takes precedence over anything in the standard class of service. All the standard work gets paused as necessary to rush the expedite item to Done. Then, the standard work resumes. At the end of the Sprint, some low priority work that was planned for the standard class of service—that is, the item or items at the bottom of the Sprint Backlog—probably doesn’t get done.
Let’s visualize this: In a pretty typical storyboard for a Scrum team, there are three states: Not Started, In Progress, and Done. Work items, perhaps user stories, move through those states. At the beginning of the Sprint, assuming the team is healthy and generally getting stuff done, everything is sitting in Not Started. I’ve put 10 stories in Not Started here because I like to see teams slicing their work small enough to fit 6-10 stories in a Sprint. (Check out our story splitting guide, by the way, if you want to learn more about how to do that.)
Let’s jump ahead a few days into the Sprint. If this team is collaborating well, their board a few days into the sprint might look like this. One story is done, a couple are in progress, and most are not started.
At this point, imagine an emergency comes up, perhaps a serious support issue the team needs to address. Time to introduce our expedite class of service into this picture, which we’ll do by adding an expedite lane at the top of the board. It’s at the top of the board because anything in the expedite lane is, by definition, higher priority than even the highest priority item in the standard class of service.
So the new emergency lands in the Not Started column of the expedite lane. As soon as this hits the board, work on the standard items pauses for the team to figure out how to handle the expedite item. They don’t bother estimating or debating it; it’s an emergency. They just get to work. Team members do what they need to do to get that emergency handled and moved across the board, then they go back to work on the standard sprint backlog items.
A few days later, the board may look like this when another emergency comes up. Again, the team pauses standard work, rushes the emergency across and then goes back to the normal work.
At the end of the sprint, it might look like this. Two expedite items done, 8 standard items done, 1 standard item in progress, and 1 not started.
So, how much did the expedite items cost? Well, a little less than the bottom two planned sprint backlog items would have.
If this support load is pretty typical, how much should the team plan in the next sprint? About 8 items rather than 10.
Were these expedite items actually more valuable than the bottom two items on the sprint backlog? Well, that’s a good thing to make visible and talk about in the Sprint Review.
On many teams, emergencies come from one source and planned items from another. This approach helps make visible the conflict between the two. Often, teams have a sense that some of the “emergencies” aren’t really emergencies but they don’t feel like they have the power to push back. The “expedite lane” approach is an example of the advice we give all the time: If you can’t fix it, make it more visible.
Start by accepting whatever comes to you as emergencies today, whether you buy it or not, make visible the impact of treating that work as more important, and then have the conversations about that outcome and use it to emerge clearer policies about what kinds of things should be allowed to interrupt a sprint and which things go back on the product backlog instead.
Now, here’s where we need the other concept from Kanban, Work In Progress limits, or WIP limits. WIP limits are about putting, well, limits on how many items can be in progress at once. In the scenario we just walked through, the team was keeping their work in progress pretty low, with only 2 or 3 items in progress at once. This made it relatively easy to handle the emergencies instead of the lower priority Sprint Backlog items. It’s much cleaner to have never started a low priority item than to have partially completed work at the end of a Sprint.
But if, instead, the team’s board looked like this on day 3 of the Sprint, they’re way more fragile to interruptions. Whatever happens, they’re likely to have partially completed work at the end of this Sprint, meaning their system is unlikely to finish the Sprint in a potentially shippable state.
The more likely your team is to get interrupted, the more important it is to keep your work in progress low. This keeps you flexible and able to handle emergencies and still end the Sprint in a clean state.
The expedite lane approach works well for teams with up to about a third of their capacity going towards emergent work. Two-thirds of your capacity is enough to still be worth planning and reviewing with a normal Scrum approach. Once you get beyond that, though, it can make more sense to just use Kanban to organize your work. You can still have a standard class of service, but instead of trying to make it fit into a time box with Sprints, just use WIP limits to keep from having too many things in progress at once. This is really the difference between a Scrum product team doing a bit of support work and a Kanban support team doing some long-running product development work.
Thanks for joining us for this week’s Humanizing Work Show. Please like and share this episode if you found it useful, and keep the questions coming! We love digging into tough topics, so send them our way.
Last updated