Unplanned work

Engineering teams that consistently miss sprint commitments often share one root cause: unplanned work is consuming more capacity than anyone realizes. Unplanned work is any task that enters your squad's workflow outside of the normal planning process, pulling players off committed work to handle bugs, incidents, urgent requests, or rework. Left unmeasured, it silently erodes your delivery predictability, burns out your best players, and makes roadmap commitments feel like guesswork. This page covers the definition, how to measure it, what good looks like, how to reduce it, and how DevStats surfaces it from your existing tools.

Key takeaways

• Unplanned work is any work that enters a squad's workflow without being part of the original sprint or iteration plan, including production incidents, urgent bug fixes, ad hoc requests, and rework caused by defects. It matters because even a modest unplanned work rate can make delivery commitments unreliable and erode stakeholder trust over time.
• Unplanned work is measured as a percentage of total capacity: unplanned work rate = unplanned issues completed divided by total issues completed, multiplied by 100. No universally published benchmark exists, but most high-performing squads keep unplanned work below 20% of total capacity per sprint, while teams above 40% typically show signs of chronic delivery instability.
• The most common mistake teams make is treating unplanned work as a normal cost of doing business without measuring it. When it goes uncounted, squads underestimate how much reactive work they carry, leading to sprint plans that are structurally impossible to complete from day one.
• DevStats surfaces unplanned work patterns automatically by connecting to your issue tracker, with planning accuracy data benchmarked against 1,000+ engineering teams. Start a free trial to see your squad's numbers in under two minutes.

Unplanned work definition

Unplanned work is any task a software engineering team completes that was not included in the original sprint or iteration plan. It includes production incidents, emergency bug fixes, urgent stakeholder requests, and rework caused by defects that escaped into production.

Technically, it is expressed as a rate: unplanned work rate = (unplanned issues completed / total issues completed) × 100. The data sources required are your issue tracker (Jira, Linear, GitHub Issues) and, for incident-driven unplanned work, your incident management tool. Teams using DevStats can see how capacity is allocated across planned versus reactive work directly from their connected issue tracker, giving engineering leaders a clear picture of where committed time is actually going.

High unplanned work rates translate directly into a business outcome: missed release dates, unpredictable feature delivery, and compounding technical debt that makes future work slower.

Why unplanned work matters for engineering teams

When squads do not track unplanned work, sprint commitments become fiction. A team that carries 35% unplanned work per sprint is, in practice, planning with only 65% of its real capacity. The sprint looks achievable on paper but fails consistently in execution, and the failure gets attributed to poor estimation rather than the actual cause.

The downstream effects reach beyond missed deadlines. Players who spend a large share of their week context-switching into reactive work report lower satisfaction and higher burnout risk. Stakeholder confidence in the engineering team erodes when roadmap dates slip repeatedly without a clear explanation. Unplanned work also inflates issue cycle time across the board, because in-flight planned work gets paused or deprioritized every time an unplanned item lands.

Within the SPACE framework, unplanned work sits at the intersection of satisfaction and performance: it degrades both simultaneously. Measuring it is the first step. What the engineering leader decides to do with that data is where the real improvement happens.

How to measure unplanned work

The calculation is straightforward: divide the number of unplanned issues completed in a sprint by the total issues completed, then multiply by 100 to get a percentage. The harder part is consistent classification. Your team needs a shared definition of what counts as unplanned, applied at ticket creation or triage, not retroactively at sprint close.

Data sources to connect: your issue tracker for ticket volume and labels, your incident management tool (PagerDuty, OpsGenie) for production incidents, and your CI/CD pipeline data to identify hotfixes that bypass normal review. No single published benchmark for unplanned work rate exists in the DORA State of DevOps reports, but industry practitioners consistently describe the thresholds below as meaningful signal. See DevStats benchmarks for how your squad compares against similar teams.

Note: these thresholds vary by team size, system maturity, and release model. A team operating a high-availability production system will carry more incident-driven unplanned work than a team in early-stage product development. Calibrate your baseline before setting targets.

Unplanned work in practice: a real example

A VP of Engineering at a 45-person SaaS company noticed that her squads were consistently completing only 60–65% of sprint commitments despite what looked like reasonable sprint plans. She pulled issue tracker data and labeled tickets by type for the previous eight weeks. The data showed that unplanned work was averaging 38% of total capacity per sprint, driven primarily by customer-reported bugs and one-off data requests from the sales team. The problem was not estimation quality. It was structural capacity leakage that had never been quantified.

She made two decisions: establish a dedicated support rotation so one player per squad handled all reactive requests without pulling others off planned work, and set a rule that sales data requests required product triage before engineering picked them up. After two sprints, unplanned work dropped to 22%. Sprint completion rate climbed to 80%, and the team's throughput on planned features increased without adding headcount. The measurement did not fix the problem. Her decisions did.

How to reduce unplanned work

1. Classify every ticket at intake. Add a required field in your issue tracker that distinguishes planned, unplanned, and support work. Without consistent classification, you cannot measure the rate accurately. Review the classification weekly at sprint retrospective, not just at the end of a quarter.
2. Create a dedicated interrupt buffer. Reserve a fixed percentage of sprint capacity, typically 15–20%, for unplanned work. This does not reduce unplanned work, but it makes your sprint plans honest. When the buffer fills, new unplanned items go to a backlog rather than displacing committed work.
3. Trace unplanned work to its source. Categorize unplanned items by origin: production incidents, rework from defects, stakeholder requests, or technical debt fires. The distribution tells you where to intervene. High incident volume points to reliability problems. High rework volume points to quality gaps in your code review process.
4. Monitor sprint-over-sprint trends. Use DevStats's sprint data to track whether your unplanned work rate is improving after each intervention. A single sprint is noise. A trend across six sprints is signal.
5. Reduce the defect escape rate upstream. Unplanned work driven by production bugs is a lagging indicator of quality problems earlier in the cycle. Tightening test coverage and code review standards reduces the incident volume that generates reactive work downstream.

Unplanned work vs. technical debt work

Unplanned work and technical debt work are both reactive, but they are not the same thing. Unplanned work is urgent and unscheduled. Technical debt work is known, schedulable, and often deprioritized in favor of features.

Use unplanned work rate to diagnose sprint predictability problems. Use technical debt tracking to evaluate whether your squad is investing enough in system health over time. High unplanned work is often a symptom of deferred technical debt, so both metrics belong in the same conversation.