It’s a myth that Scrum Teams don’t plan. Scrum Teams plan at the Sprint Planning event and when refining work items. They also create a forecast or a roadmap that shows their plans across multiple Sprints.
Scrum Teams plan frequently to navigate complicated environments where new information emerges constantly. The team inspects new knowledge and adapts their approach to take advantage of what they've learned.
What happens when the team is confronted with unplanned work mid-Sprint? That’s what we’re going to delve into here.
Unplanned work happens
No matter how much a Scrum Team plans, there are times when someone asks them to undertake unplanned work mid-Sprint. When that happens, the Developers and the Product Owner should meet to discuss how to respond.
Why the Developers and the Product Owner? The Product Owner is accountable for ordering the work items in the Product Backlog. They alone can decide whether this work warrants them adding it to the Product Backlog and whether it is important enough to consider adding it to the Sprint Backlog for the current Sprint.
On the other hand, the Developers own the Sprint Backlog, and they alone can determine whether they can undertake this work without putting the Sprint Goal at risk.
If the Product Owner does ask to add work items to the Sprint, the Developers may refuse, or they might negotiate with the Product Owner to determine which work to remove from the Sprint to accommodate the new request. We should never make changes to the Product Backlog that will put the Sprint Goal at risk.
Some Scrum Teams face a lot of unplanned work. For example, many Scrum Teams handle production support issues in addition to new development. For many organizations, production support is unpredictable and cannot be delayed until the next Sprint — they must handle requests immediately. Although this kind of work is unplanned, it is critical to the product's success.
Following are a few options for how to handle unplanned work. (If you have other ideas, add them in the comments section below!)
Option 1: Leave some capacity free, and add unplanned work to the Sprint Backlog as it comes in
In this option, Developers estimate during Sprint Planning how much unplanned work they expect to receive in the upcoming Sprint and leave some capacity free to deal with it. It’s a tricky proposition because how can we plan for the unplanned? We can’t, but we can make educated guesses by looking at past performance. What percentage of the Scrum Team’s time during previous Sprints was eaten up by unplanned work? Is the unexpected work highly variable, or is it fairly steady? The answers to these questions can help us to estimate how much capacity to leave free for last-minute requests that might come in during the Sprint.
As the unplanned work comes in, if the Product Owner and Developers agree to add it to the Sprint, they should include it in the Sprint Backlog for transparency and to ensure that the team can track the progress of all work in the Sprint.
Option 2: Leave some capacity free, but don’t add unplanned work to the Sprint Backlog
If the unplanned work consists of a set of smaller tasks, the Scrum Team might consider whether it is worthwhile to add this work to the Sprint Backlog despite the lack of transparency. In large volumes, adding these smaller tasks to the Sprint Backlog can create an administrative burden. In that case, the team can still take the approach of not fully loading the Sprint as in option two, but they may handle the unplanned work outside the Sprint's scope. In this case, the team leaves a part of their capacity undedicated to free the team from the administrative burden of adding it to the Sprint Backlog.
Option 3: A separate team handles unplanned work
If unplanned work is significant and frequent, the Scrum team might decide to split up, dedicating a single team to production support. Scrum teams are self-managing, which means that they control the way that they approach their work, including how to structure the team itself.
Strategies for limiting the impact of unplanned work
As we discuss in the Professional Scrum Master course, every Sprint is an agreement between the organization and the Scrum team. The Scrum Team needs to be as free as possible to focus on the work of the Sprint and regular refinement activities. In exchange, the organization will receive an increment of usable product frequently. However, it can be difficult in some organizations to completely eliminate unplanned work. If your team faces unexpected work routinely, below are a few strategies we can use to cope.
Finish the current work item first
When unplanned work strikes, it can be tempting to stop what we’re doing and pivot immediately to the emergency. Don’t do it! Instead, finish the current work and then begin the next highest-ordered work item. Why? Because when we put work on pause and start working on a different thing before we have finished the first thing, we have a lot of half-baked work sitting around, creating waste. That “bread” can’t sit on the counter forever before going stale. It will also take longer to complete that original work item because we will have to regroup when we eventually return to it.
Limit work in progress
If the team is facing a lot of unplanned work, it is even more pressing for us to limit our work in progress. Work in progress refers to the number of items we are working on during the Sprint. If we have a lot of work in progress and get hit with unplanned work, we have a lot of juggling to do before we can pivot to that additional work. By limiting work in progress, we don’t have a lot of work to put down or complete before we can shift gears to focus on the unplanned work.
Cut the work smaller
Another strategy for teams facing a lot of unplanned work is to cut our planned work into smaller pieces. Cutting the work smaller will enable us to finish our current task and pivot more quickly if unplanned work comes knocking at our door.
Pairing up
Rather than each Developer taking on separate work, pairing involves two Developers working on the same item. This strategy delivers two benefits. One, in effect, pairing limits work in progress. Second, it gives the team greater flexibility when faced with unplanned work because they can finish current work items faster or get one of the Developers in the pair to pivot while the other remains on the original task. Pair programming also offers learning benefits for the team and enables the team to deliver more creative solutions to difficult problems.
In software development, a common term for pairing two developers together is pair programming. Several years ago, I was the Scrum Master for a team who was contemplating trying out pair programming. I was skeptical of the need for pair programming, but the Developers decided to try it. They were trying to reduce the run time of a batch job by 10% and ended up taking a job that took in excess of 8 hours to run completely, and they reduced the run time to just 15 minutes, while also improving quality and stability. I never questioned the efficiency of pair programming again!
Conclusion
No matter how much a Scrum Team plans, there are times when someone requests unplanned work mid-Sprint. When that happens, the Developers and the Product Owner should meet to determine whether to add the requested work to the current Sprint. Scrum Teams should decide up front how they will handle unplanned work — will it be added to the Sprint Backlog or completed outside of the scope of the Sprint? If there is frequent unexpected work, should the team leave some capacity free to handle it, or should a separate team undertake the work? These are questions only the Scrum Team can answer, and the approach may evolve as we learn more about the customer's needs.
Sign up for Rebel Scrum’s Applying Professional Scrum class to learn more about the Scrum framework. If you are a Scrum Master looking to take your team to the next level, signup for Rebel Scrum’s upcoming Professional Scrum Master course.
Rebel Scrum offers private group training and custom workshops that provide numerous benefits. Private group training enhances collaboration, innovation, and knowledge sharing among teams. Custom workshops help teams define products and self-organize effectively. Both empower organizations to build high-performing teams and drive product success.