Unplanned Work Is the Capacity Your Roadmap Never Counts

Unplanned work is any work that arrives outside the plan and cannot wait. The 2016 State of DevOps Report defines it as including "any break/fix work, emergency software deployments and patches, responding to urgent audit documentation requests, and so forth." It is the reason a team of twenty rarely delivers twenty engineers' worth of roadmap.

We find most leaders know the gap exists and few have a number for it. Without a number, the shortfall shows up as a vague velocity problem, or as a request for more headcount that nobody can justify.

In this post we cover the figures on unplanned work that hold up under a close read, the capacity math for a 20-engineer team, why the drain stays invisible, how to measure your own number in two weeks, what moves it, and when a high share is the right trade.

The Numbers on Unplanned Work That Survive a Close Read

Three sources get quoted constantly, often loosely. We went back to each one, because they measure different things and the differences matter when you build a plan on them.

Source	What it measured	Figure	Caveat
2016 State of DevOps Report	Self-reported time on unplanned work or rework	21% for high performers, 27% for low performers	A 2016 survey, so treat it as a range, not a benchmark
Stripe, The Developer Coefficient	Estimated hours a week on maintenance, debugging and bad code	17.3 of an average 41.1-hour week	Maintenance is broader than unplanned work, and the hours are estimates
Equal Experts telco case	Value-add versus non-value-add time at one company	A 20/80 split, against the manager's predicted 80/20	A single case, useful as a ceiling, not a norm

The 2016 State of DevOps Report also found high performers spent 49% of their time on new work, against 38% for low performers. That is the trade in one line, since every point of unplanned work comes out of new work.

Stripe's Developer Coefficient survey put maintenance at 17.3 hours of a 41.1-hour week, about 42%, and estimated that roughly four hours a week on bad code cost nearly $85 billion a year worldwide. We note that the $85 billion refers to the bad-code hours, not to the full 17.3, a distinction the figure often loses.

Equal Experts describe a British telco whose teams averaged 80% of their time on unplanned tech work. We use it to show how far the drain can go when nobody measures it, not as a typical figure.

Capacity Math for a 20-Engineer Team in Four Steps

Percentages do not change plans, but engineering capacity expressed in full-time engineers does. We work the math in four steps, using the State of DevOps range as an illustration until you have your own measurement.

1. Start From Naive Capacity

Count the engineers assigned to the roadmap. A 20-engineer team is planned as 20 engineers of feature work, before holidays, hiring loops and meetings. That number is the fiction most roadmaps are built on, and we write it down so the gap is visible.

2. Subtract Unplanned Work at Your Measured Rate

At 21% unplanned work and rework, the high-performer figure, the team loses about 4.2 engineers of planned capacity. At 27%, the low-performer figure, it loses about 5.4. Either way, between four and six people's worth of work is going somewhere the roadmap does not show.

Your own rate may sit well outside that range. A team with fragile systems can run far higher, as the telco case shows, so the illustration is a floor for discussion, not a forecast.

We split the lost capacity by source as well, into incidents, urgent requests and rework, because each has a different owner and a different fix. Capacity planning that treats them as one bucket tends to fund the wrong remedy, such as more on-call cover when the real driver is rework from rushed releases.

3. Account for the Cost of Interruptions

A short interruption costs more than its duration, because the engineer also has to get back into the work it broke. We do not use a fixed multiplier from someone else's study. Instead, the team agrees on one for short interruptions and applies it consistently, so the estimate is honest about context switching without pretending to precision.

4. Price the Gap With Your Own Loaded Cost

Multiply the lost engineers by your own fully loaded cost per engineer. We deliberately leave the salary number to you, because it varies by region and seniority and any figure we picked would be wrong for most readers.

The result is a number a finance partner understands. It reframes "we need more people" as "we already pay for several people who spend their time on work nobody planned", which is a far easier conversation.

Why Unplanned Work Stays Invisible

If a factory scrapped a fifth of its material every day, someone would be fired. Engineering absorbs a similar loss as business as usual, because unplanned work arrives in small pieces, a thread here, an urgent fix there, and never appears as a single line item.

Our tools are built for what we plan to do, not what we did. Backlogs record intent, so the incident that took an afternoon often has no ticket at all. We have also seen engineers fold small fixes into feature tickets to avoid overhead, which hides exactly the work we are trying to count.

The result is a gap between what leaders see, a velocity problem, and what engineers feel, a week that keeps getting taken away. Closing it starts with measurement, not with a new process.

Measure Your Own Number in Two Weeks

We would not buy a platform to get the first number. A defensible estimate takes two weeks and three simple instruments.

• A one-question weekly survey. Every Friday, ask each engineer what share of their week went to work that was not on the plan, such as incidents, urgent requests and bugs.
• Ticket tagging. Sort the last two weeks of completed work into new value, maintenance and rework, where rework means fixing something that was meant to be finished.
• An interruption log for one week. Engineers note each interruption and its rough length, so the agreed multiplier has something to apply to.

Aim for directionally correct, not exact. The point is a number good enough to change a plan, and individual blame has no place in it, because high unplanned work is almost always a property of the system rather than of the people.

What Actually Moves the Unplanned Work Share

The same 2016 report found that "continuous delivery predicts lower levels of unplanned work and rework in a statistically significant way." Smaller, more frequent changes are easier to test and easier to roll back, so fewer of them turn into emergencies.

Diagnosis is the other lever. Much unplanned time goes to root cause analysis, finding out what broke rather than fixing it, which is why we think the fastest gains often come from cutting investigation time. Our guide to reducing MTTR by shortening diagnosis covers the method, and our note on why runbook automation targets execution, not diagnosis explains why automating the fix rarely moves the number much.

If you weigh a tool against that FTE figure, compare it on cost too, and prefer vendors with published, usage-based pricing so the comparison is honest. Be careful with productivity tools that speed up writing code while raising rework, a trade our incidents per pull request data study examines.

When a High Unplanned Work Share Is the Right Trade

Not every team should drive the number down. An early product searching for fit changes direction weekly, and work that arrives unplanned is often the most valuable work it does. Forcing it into a plan would slow the learning.

Some periods also justify a spike. A large migration, a security response or a major customer launch will raise unplanned work for a while, and that is a choice, not a failure, as long as the team knows it is spending capacity and for how long.

The problem is a high share that nobody chose and nobody can see. Our post on why toil went up despite AI tools covers how that share can grow even when teams believe they are automating it away.

Budget for Unplanned Work Before It Spends Your Roadmap

Every roadmap already pays for unplanned work, whether it plans for it or not. We would measure the share for two weeks, convert it to engineers, and put that number in the plan, so unplanned work is budgeted capacity rather than a recurring surprise.

Start with the Friday survey this week. Operate runs dedicated AI agents inside your own infrastructure that investigate production issues through read-only adapters, and every finding cites its evidence.