Dealing with unexpected work

Problem Statement

One of my large corporate clients has teams who’re all struggling to cope with what they see as large amounts of unplanned work. There’s a great degree of commonality in the conversations that I have with the teams. Most of them are using Scrum at the team level.

Opening Gambit

The first thing to do (IMHO) is to build a model of the different types of unexpected work that is hitting the team. I usually use “predictability” and “plannability” as my two classifying dimensions. That leads to three types of unexpected work (the fourth category is planned work):

• Unpredictable and Unplannable. This is stuff that you simply don’t realise is out there. It hits you out of the blue
• Predictable but Unplannable. You know there are predictable patterns of work, but you don’t know the specifics. For example you know you get about 100 tickets a week from your support queues.
• Plannable but Unpredictable. You can plan the work, but you don’t realise you have to. For example your priorities might shift towards things further down your backlog.
• Plannable and Predictable. The ideal case.

Understanding what the categories of the unexpected work can trigger more strategic thinking. For example, you might have a blind spot in your priorities (Note: In this client’s case, they’re using OKRs to articulate intent). You might also determine that you are able to turn down some of these requests (or reroute them to a more appropriate team).

But What About Today’s Symptoms?

The next thing to do, is find out whether it can wait until the next sprint. This allows the team to maintain the momentum in their current sprint while prioritising the new work.

Depending on the stakeholder making the request, your relationship, the amount of power held by you/them, your shoe size, their attitude to hats ^(*), there may be a right way and a wrong way to approach this. I’ve usually found “young” organisations (from an agile maturity perspective) require more visible signs of authority such as messages like “the Scrum process we’re following has a mechanism for accepting late changes, and they go to the top of the product backlog ready for the next sprint”. In order for the team to maintain a good flow of work, they may also need to schedule in a backlog refinement session to get that new work request ready for a sprint.

What if the work can’t wait?

There will be situations when the work can’t wait even a single sprint and needs to be tackled now. To have a controlled acceptance of the work into the team’s current sprint, it’s worth exploring a few aspects of the work.

• Does the new work align to the current sprint goal?
• How big is the new work (for example T-shirt sizing)?
• Is the work a direct replacement for something already planned?

If the new work aligns with the sprint goal, then the substitution of already planned work can be relatively straightforward. If the new work doesn’t align, or worse, is in direct conflict with the sprint goal, then it’s worth exploring the team’s strategic priorities to detect potential blind spots. If they’ve been able to size the new work, they should be in a position to swap a similar amount of work in the sprint.

What if the team’s not in a position to deliver less than forecasted?

The team might be in some situations where sprint forecasts are used by other teams as part of their planning, and delivering less than forecasted amounts would be problematic. While it’s not a great situation to be in (and is potentially a sign that the overall level of agile maturity is low-ish), it is something that teams sometimes have to contend with.

In this scenario, the easiest strategy is to plan with a buffer. A bit like the old MoSCoW prioritisation technique for timeboxes. The DSDM guidance (the origin of the terms Timebox and MoSCoW prioritisation) typically recommends no more than 60% of a timebox is Must Have requirements (for the scope of the timebox). This means that while the team will deliver as much as it can, consumers of the timebox should only really expect 60% of the total timebox plan with certainty, the remainder being variable.

Buffers work well when they’re in the form of a percentage of remaining time. This means the available buffer drops as the sprint executes. The danger of a fixed time buffer is it’s easy to misunderstand how much change/disruption the team can tolerate towards the latter part of the sprint.

What if the buffer amount needed changes drastically from sprint to sprint?

If the Scrum team is unable to apply any of the previous bits of advice, then there’s a good chance that there is too much uncertainty in the team’s context for Scrum to be an effective team process, as Scrum relies on being able to predict a sprint length into the future. The team may get better results from adopting Kanban as a team process, and tuning their WIP limits to keep enough slack in the system to respond to their changing demands.