How to deal with unplanned work?

There are three guarantees in life:

Unplanned work, Death and Taxes

I can’t help you with the last two but let’s talk about how Scrum teams can deal with unplanned work.

First of all, let’s just agree on what is considered “unplanned work”. Generally speaking, anything that was not on the Sprint Backlog at the Sprint Planning, this may include

• Urgent issues, production issues, hot fixes
• Missed requirements/scope change/major changes in acceptance criteria
• You may find it helpful to clarify and agree on the definition of unplanned work with your team also

It’s important to recognize that urgent and unforeseen work does genuinely arise, and must therefore genuinely be dealt with and not just “absorbed”. Unplanned work can give us insights into opportunities to improve how teams plan and the quality of their sprints.

Does everyone remember the 3 pillars of Scrum, why does it matter that we revisit the 3 pillars when we are dealing with unplanned work?

• Transparency – seeing the unplanned work and surfacing that there is unplanned work with the Product Leader and Manager (stakeholders if required)
  
• Inspect – inspecting the unplanned work and having a conversation around is this unplanned work important enough to disrupt the sprint backlog (planned work)
  
• Adapt – making informed decisions about the unplanned work, the Product Leader should be able to decide with the support of the team. The Product Leader can:
  • Decide that the unplanned work is urgent enough to change the team’s focus, in which case the Sprint Backlog may be updated, items in the Sprint Backlog may be swapped out with the unplanned work. The team may conduct a meeting to refine the item that has been brought in mid-sprint.
  • If a majority of the work and goal of Sprint has changed, the Sprint may be canceled by the Product Owner – the entire Scrum team will conduct Sprint planning again based on the remaining capacity and estimate what they can bring in for the remaining sprint.

How to deal with production issues that come up during a sprint?

1. Ensure you address the issue (put out the fire IF it is a fire, not all production issues need to be addressed right away. The Product Owner should decide whether the production issue is an urgent one and whether it should be brought into the sprint (should be able to articulate why it is more important than the team’s current planned commitment. Provide a quick estimate to your Product Owner will help them understand the impact of this issue.
2. If it is decided that the production issue needs to be addressed right away in your initial investigation, ensure you track the work by bringing it into the sprint (you’ll see a spike in your burndown chart and this will help us see the increased scope and the impact on how the team is progressing to done)
3. The team should help the Product Owner understand any item that are being put on hold(or are impacted) as a result of the production issue, as well as any item that need to be removed from the sprint to reflect the impact of bringing in the production issue into the sprint.
4. Learn from the production issues:
   1. Include the production issues during Sprint Review as a part of the list of work completed by the team. 
   2. During Sprint retrospective, the team may reflect on:

• What were the production issue(s)?
• Is there a pattern here?
• What could we have done to avoid issues of this kind? What are our learnings? How did this production issue affect our ability to meet our sprint commitments?
• Do we want to do anything different to avoid production issues of this kind?

Should you anticipate production issues by reserving a number of points for them every sprint?

The short answer is no. What you want to do instead is to always be ready to respond! 

1. Ensure your commitment for the sprint is ranked according to business value and priorities, taking into account technical dependencies–collaborate to work on the list of product backlog items according to this ranked list – so we maximize return on investment by focusing the whole team on completing the highest value items first. 
2. When a product issue comes in and we decide it is important we address it right away, we remove a product backlog item from the bottom of our ranked list to reflect the impact of this production issue. How do we know what to remove? We may estimate and take an equivalent Product Backlog Item out of the sprint. 

The best way to address production issue is to build quality in and learn what caused these production issues to prevent them.

To anticipate changes require us to actively prioritize any unplanned work in comparison with planned work and ask the question “should this impact our existing sprint commitment? What’s got to give? What do we need to remove from the sprint as a result of this unplanned work?” 

The team should not be absorbing the work by default as this can mess with your velocity and lead to burn out – when the team is working overtime constantly to play catch up the velocity is inflated and is based on inconsistent sprint length. So the next time we come to ask what can we get done in a sprint, we really don’t know realistically how much we can get done without working over time. Sprint boundaries are important!  

If a planned sprint is materialistically impacted (more than 50% of the work are impacted by unplanned items), the Product Owner may suggest abandoning the sprint plan and replan your sprint as a team – it happens, but shouldn’t happen too often.  The Product Owner needs to be the one to cancel the sprint and initiate any replanning.