Your roadmap needs a budget for unplanned work

The roadmap review says the next release is still on track. Then Monday starts.

A production alert pulls two engineers into diagnosis. A support escalation needs a data fix. Security asks for an urgent library update. By Thursday, the team has spent a meaningful part of its week on work that never appeared in the plan. The roadmap date moves, but the explanation is usually vague: priorities changed, something urgent came up, or the sprint was disrupted.

The forecast did not fail because the team estimated every roadmap item badly. It failed because one source of demand stayed outside the model.

Unplanned production work belongs in the same delivery model as roadmap work. If it consumes capacity, changes priorities, or interrupts active tasks, your forecast must represent it rather than treat it as an exception.

The forecast is missing a demand class

Most delivery plans start with the visible backlog and the people expected to work on it. Production incidents, operational requests, urgent defects, compliance fixes, and support escalations often sit elsewhere. They arrive through another queue, use another label, or bypass the system through chat and direct messages.

That separation makes the roadmap look cleaner than the work system really is. The team appears to have a stable amount of planned capacity until operational demand claims it. Leaders then compare actual delivery with a plan that assumed those arrivals would not happen.

The problem is variability, not merely volume. Ten hours of maintenance spread across a week does not affect work in the same way as ten hours that arrive during a release and require several specialists at once. Interruptions also create a second effect: active roadmap work waits while people diagnose, coordinate, and later reconstruct where they stopped.

Wiesche (2021) studied four agile software teams and found three broad sources of interruption: programming impediments, team interactions, and demands from the external environment. The study also matters for what it does not support. Some interruptions helped teams complete work or respond flexibly. Teams used improved information retrieval and reduced dependencies to manage interruptions.

A better distinction is whether the demand is necessary, how it enters, and what it displaces.

Hidden work creates hidden queues

Imagine a team with six active roadmap items. An incident arrives and two people switch immediately. The original items remain marked as active, even though progress has stopped. A second urgent request enters before the incident closes. The board now understates work in process because the operational work is absent or recorded in another system.

Nothing in this mechanism requires anyone to work slowly. The system has simply accepted more work than its current capacity can finish at the expected rate. Waiting rises inside active items, ownership fragments, and completion dates become more sensitive to the next arrival.

There is some evidence that controlling work in process helps in software maintenance. Concas et al. (2013) built simulations from maintenance data collected in two industrial settings. Their WIP-limited process reduced the average completion time for maintenance requests compared with the modelled process without a limit. This is useful support for the flow mechanism, but it is not a field experiment on production incidents. It does not tell us that every team should use the same limit or reserve the same percentage of capacity.

The wider Kanban evidence also calls for restraint. Ahmad et al. (2018) mapped the software Kanban literature and found many reported benefits and practical experiences, but little rigorous cumulative evidence. Visibility and WIP control are reasonable operating choices. A universal promise that they will improve delivery predictability is not.

No study in this evidence set directly tests whether a capacity budget for production work improves forecast accuracy. The practical design below is therefore a mechanism-based policy, constrained by the evidence rather than proven by it.

Start with arrivals, effort, and displacement

Before choosing a capacity number, reconstruct what has actually been happening. Use the last 8 to 12 weeks of Jira, Azure DevOps, incident, and support data. The window is a practical starting point, not a scientific threshold.

For each unplanned item, capture four things:

• when it arrived and when work began;

• why it qualified as urgent;

• how much engineering effort it consumed;

• which planned item slowed, paused, or left the forecast because of it.

The last field is often missing. Teams count incidents but rarely connect them to the promise that moved. Without that link, operational demand becomes a general explanation rather than a testable part of the delivery model.

Keep the classification small enough to use. Production incident, urgent defect, operational maintenance, and avoidable expedite may be enough. Look for clustered arrivals, repeat sources, and scarce skills. Averages hide the weeks that break commitments.

Make the displacement rule explicit

A capacity budget is not a private allowance that teams quietly subtract from roadmap work. It is an agreement about how the organization responds when unplanned demand arrives.

Define one intake rule. For example: production work enters through a shared operational queue, with a named owner who confirms severity and records the reason for urgency. People can still respond quickly. The rule makes the response visible without forcing an incident through normal backlog refinement.

Then define one displacement rule. If an item requires immediate engineering capacity, the team names the planned work that will pause or the commitment that needs review. The new work does not sit on top of the old plan. Leaders see the trade at the moment it is made, not at the next roadmap review.

This is where service classes can help. A genuine production emergency may receive immediate service. Routine maintenance may wait for the next replenishment decision. An executive request does not become urgent merely because it arrived from an executive. The policy protects responsiveness while preventing every request from claiming emergency treatment.

The study does not test an intake policy. Formalising, channelling, and prioritising interruptions are mechanism-based recommendations here, not findings from Wiesche (2021). The intake policy handles the arrival. Dependency reduction and faster diagnosis address the reasons an arrival can consume so much capacity.

Budget from evidence, then revise it

Do not begin with a fashionable rule such as reserving 20 percent for unplanned work. Start with your observed distribution.

Estimate how much capacity unplanned demand consumed in each recent week. Separate typical weeks from severe but plausible ones. Choose a budget that matches the commitment risk you are willing to carry, then state what happens when demand exceeds it. A team might reduce the next replenishment, pause a lower-priority item, or ask a portfolio owner to revise the release scope. The right response depends on the cost of delay and the severity of the production problem.

Review the budget on a fixed cadence. If it is always unused, the number may be too high or the classification too broad. If it is exceeded every week, the budget is not protecting delivery. It is documenting a recurring quality, architecture, dependency, or support problem that needs its own intervention.

Do not let reserved capacity hide demand. Track arrivals, effort, and displaced work even when the budget absorbs them. Otherwise the roadmap may look more reliable while the underlying production burden keeps growing.

On Monday, take one recent roadmap miss and rebuild the missing demand beside it. Name the work that arrived, the capacity it used, and the item it displaced. Then agree on one intake rule and one displacement rule for the next replenishment cycle. Your next forecast will still contain uncertainty, but it will no longer depend on pretending that production work is exceptional.

References

Ahmad, M. O., Dennehy, D., Conboy, K., & Oivo, M. (2018). Kanban in software engineering: A systematic mapping study. Journal of Systems and Software, 137, 96–113. https://doi.org/10.1016/j.jss.2017.11.045

Concas, G., Lunesu, M. I., Marchesi, M., & Zhang, H. (2013, May 16). Simulation of software maintenance process, with and without a work-in-process limit. Journal of Software: Evolution and Process, 25(12), 1225–1248. https://doi.org/10.1002/smr.1599

Wiesche, M. (2021, March 1). Interruptions in agile software development teams. Project Management Journal, 52(2), 210–222. https://doi.org/10.1177/8756972821991365