In every Scrum class I get asked how to deal with interrupt-driven work. Scrum is very effective when dealing with planned work, but what about unplanned work that appears during a sprint? Can we use Scrum to deal with both plan-driven and interrupt-driven work? Yes, if there is statistical predictability to the must-do-now interrupt-driven flow stream. Let’s dissect what that means and how to apply it.
Flow Streams
Imagine there are two streams of work, each with different flow characteristics. There is the plan-driven flow stream and the interrupt-driven flow stream.
The plan-driven flow stream is the one most typically associated with Scrum and is captured in the product backlog. The order of the items in the backlog represents the “plan” for how the work should unfold. The Scrum team plans to work on the items at the top of the backlog before the items further down in the backlog. When the Scrum team performs sprint planning, it’s determining a plan for the next sprint. Scrum therefore naturally aligns with a plan-driven flow of work.
As the Scrum team learns into the problem and the solution, work on a plan-driven stream can change. However, those changes are handled by standard product backlog refinement (grooming) and therefore are included in the plan-driven stream. Importantly, these types of changes don’t interrupt the work of the current sprint.
The interrupt-driven flow stream captures unplanned work that appears during a sprint. For example, an important defect is reported, or a system outage occurs, etc. If the Scrum team chooses to immediately address the unplanned work, it will interrupt the plan-driven work of the current sprint.
Default Scrum Approach: Don’t Interrupt the Current Sprint
Organizations are interested in whether a plan-driven flow stream and an interrupt-driven flow stream can be provided to the same Scrum team. Scrum has a default answer to this question: yes!
Scrum has a rule: “No goal-altering changes once a sprint starts.” Basically, once the sprint goal has been established and sprint execution has begun, no change is permitted that can materially affect the sprint goal.
Based on this rule, we don’t interrupt the planned work of the sprint. Instead, we create a new product backlog item for the unplanned work and insert it in the product backlog in the correct priority order so it will get planned into a subsequent sprint. The default Scrum approach is to treat unplanned work the same as planned work. We just merge the two streams of work into the same product backlog.
I know what you're thinking. What if the Scrum team can’t defer the unplanned work until a future sprint because the work is urgent?
Urgency: Must-Do-Now vs. Would-Like-To-Do-Now
Let’s use an example. Assume today is Black Friday and our primary ecommerce system has just gone down, and the company is losing a million dollars a minute in sales. Is it economically sensible for the Scrum team to say, “Just create a new product backlog item for that system outage and we’ll address it in the next sprint?”
Of course not! This type of interrupt cannot be ignored since it has a must-do-now cost of delay (CoD).
Any item with this type of cost of delay has an urgency that must be addressed immediately.
The Scrum rule of “No goal-altering changes once a sprint starts” is generally sensible since making changes during the current sprint is wasteful. However, we must act in an economically responsible way. In this example, the cost of not interrupting the planned work of the sprint is far more expensive than the waste of interrupting, so we will interrupt the planned work.
However, if the unplanned work is not of type “must-do-now,” but rather of type “would-like-to-do-now,” then the urgency of this work doesn’t justify interrupting the planned work of the sprint. Instead, the unplanned work should be inserted into the product backlog in the correct priority order as previously discussed and treated the same as planned work.
Frequency
There is one last important factor to consider, the frequency of must-do-now unplanned work. Frequency of occurrence affects our approach to dealing with these items. If unplanned work is a rare occurrence, then just about any reasonable approach to dealing with it will work.
For example, imagine the Scrum team does two-week sprints and once a year (one out of 26 sprints) unplanned work appears and the team must decide to interrupt or not interrupt the planned work of the current sprint. In most organizations this just isn’t a big enough issue that we ought to be creating special processes to deal with it.
On the other hand, if urgent unplanned work is frequently interrupting sprints, then we do need a practical solution.
Create Two Teams and Split the Flow Streams
Assume that the frequency of must-do-now unplanned work is high enough to require a solution. There are two common solutions.
In the first solution, organizations will create two teams and split the flow streams.
A common example is when the plan-driven stream is provided to a Scrum team and the interrupt-driven stream is provided to a Kanban team.
Organizations that adopt this approach have decided that the overall flow would be better if the two different flow streams went to different teams. In this case no one team must handle two streams with different flow characteristics.
There are, however, many valid reasons why organizations don’t want to create a separate team to handle the interrupt-driven stream (e.g., additional cost, skillset availability, etc.).
Provide Both Flow Streams to the Same Team
The second solution is to provide the plan-driven flow stream and the interrupt-driven flow stream to the same Scrum team. This works when there is useful statistical predictability to the must-do-now interrupt-driven flow stream.
Here’s the “good” news. If your planned work is frequently getting interrupted with must-do-now items, then future interrupts are somewhat predictable based on the pattern of past interrupts. If your team captures its work items in an electronic tool, it should be able to collect the tickets of previous must-do-now interrupts and perform a statistical analysis of the associated data.
Let’s say the analysis indicates that, on average, the Scrum team spends about 30 hours of time each sprint working on unplanned, must-do-now interrupts. With this data, we could direct both the plan-driven stream and the interrupt-driven stream to the same Scrum team. That Scrum team would then buffer time during sprint planning to account for the predicted interrupt-driven work it will likely encounter during the sprint.
Exactly how much time to buffer depends on the results of the analysis and how confident the team wants to be that it has sufficient buffer to handle the unplanned work. Maybe the analysis shows that 30 hours would work 50% of the time (i.e., half the time the team would have more than 30 hours of unplanned work in a sprint). The analysis might also show that 45 hours would work 85% of the time. The team could choose the number of hours to buffer based on its desired confidence level.
Of course, if the historical data does not lead to any useful pattern, then this approach won’t work. For example, if we try to answer the question “How many hours should we buffer at the sprint planning meeting,” and the historical data is all over the place (e.g., you are just as likely to need zero hours as you are 500 hours), then the Scrum team would have no clear guidance on how to proceed. In this case the organization may choose to direct the flow streams to two different teams as I previously discussed.
Summary
Can the same Scrum team handle both plan-driven and interrupt-driven work? The default answer in Scrum is yes, and we merge both streams of work into the product backlog.
This default solution isn’t practical when dealing with unplanned work that has must-do-now cost of delay. However, if there is useful predictability to the must-do-now interrupts, we can reserve a capacity buffer during sprint planning to deal with the predicted interrupts we are likely to see.
If no such useful predictability exists, then we can't provide both flow streams to the same Scrum team. Some companies in this situation will choose to create a second (likely Kanban) team to handle the unplanned work.