VeloWiseengineering delivery intelligence

Engineering Interrupt Load: Measuring the Work That Arrives After Planning

Every sprint plan assumes some amount of quiet. Interrupt load measures how much of that quiet actually existed: the share of a sprint’s work that arrived after planning. For small teams that also run production, it is often the single number that explains missed commitments.

For: Engineering Managers, Team Leads, Directors of Engineering, SRE and platform leadsUpdated
Where the sprint actually wentExample delivery data
  • Planned roadmap work 48%
  • Added mid-sprint 14%
  • Production bugs 22%
  • Support & operations 16%

Only 48% of the sprint went to the plan the roadmap assumed.

Interrupt load is the share of a sprint spent on work nobody planned — visible only when you measure it.

What interrupt load is

Interrupt load is the share of all work a sprint handled that was added after the sprint started. “All work handled” means the original commitment plus everything added — including work that was later removed or not finished, because it still took attention.

Added-work load = work added after sprint start ÷ (original commitment + work added after start)

The careful name matters. Not everything added after planning is an interruption. A product manager splitting a story, or a planned follow-up created mid-sprint, is scope arriving late, not an interruption. So there are two numbers:

  • Added-work load: everything added after start ÷ everything handled. Always measurable when sprint dates are known.
  • Interrupt load: the same ratio, but only when additions can be classified — bugs and defects, production support, operational work and emergencies (Highest / Blocker / Critical priority) — with enough confidence to call them interruptions.

Why it matters

A plan that fills 100% of typical throughput with planned work assumes zero interruptions. If, historically, a quarter of the work a team handles arrives after planning, that plan was never achievable, and the resulting carryover says nothing about how well the team executed.

Interrupt load also moves the conversation from anecdote to planning. “We keep getting pulled into support” becomes “22% of the work we handled last sprint was added after start, and 14 percentage points of that were bugs and support”. That is a number a manager can reserve capacity against, negotiate with stakeholders, or use to argue for a rotation.

For small teams it matters most, because there is nobody else to absorb interruptions. See small-team sprint planning.

How to calculate it from Jira

  1. Get sprint start and end dates. Without them, work present at start cannot be told apart from work added later, and interrupt load is unknown.
  2. Identify issues added after sprint start, allowing a short planning grace period (for example 24 hours) so the tail end of planning is not counted.
  3. Classify each added issue: emergency (highest priorities), bug / defect, production support & operational, planned scope addition (features, testing, review, technical debt, research) or unknown.
  4. Divide added work by total work handled, in story points or issue counts.
Data availableWhat you can say
Sprint dates + Sprint field history, most additions categorised“Interrupt load” — exact
Sprint dates + Created dates only“Added-work load” — a minimum; older issues pulled in mid-sprint look planned
Many added issues in “Other”“Added-work load” — additions are known, their nature is not
No sprint datesUnknown — insufficient data

Issue type and labels decide the category

Classification relies on how the team uses Jira. Issue types (Bug, Incident, Support Request), labels (support, ops, hotfix) and components are mapped to categories, and the mapping should be editable — every team uses Jira differently. When more than about 30% of added work lands in “Other”, the honest label is added-work load, not interrupt load.

How to interpret the number

Original commitment vs final scopeExample delivery data
  1. Sprint starts64 issues committed
  2. Day 3+5 added
  3. Day 7+8 added
  4. Day 10+5 added
  5. Sprint ends82 issues in scope
Original commitment
64
Final scope
82
Scope growth
+28%

58 completed looks like 71% of final scope. Against the plan the team made, and the 18 issues that arrived after it, the story is different.

Comparing completed work only with final scope hides what happened during the sprint — compare with the original commitment too.

  • Under ~10%: planning is mostly holding. A small buffer is enough.
  • 10–20%: common for product teams that also own production. Reserve explicit room.
  • Over 20%, consistently: the sprint plan is covering less than four-fifths of what the team actually does. Plan to that reality or change the intake.
  • Look at the split, not just the total. A high share of planned scope additions is a refinement problem; a high share of bugs is a quality problem; a high share of support is an ownership or rotation question.

Watch the trend. One incident sprint will spike interrupt load. A load that creeps up over five sprints usually means operational responsibilities have grown without anyone adjusting capacity for feature work.

Apply this to your team’s delivery

Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.

Create Free Account Try sample project

Common mistakes

  • Calling every addition an interruption. Late-arriving planned scope is not the same as a production incident.
  • Assuming bugs are always interruptions. A bug chosen at planning is planned work. Only added bugs count.
  • Ignoring added work that was not finished. It still consumed attention; the denominator is everything handled, not only what completed.
  • Treating a minimum as exact. Without Sprint field history, say “at least”.
  • Using it to judge individuals. Interrupt load is a property of intake and ownership, not personal focus.

What to do about high interrupt load

  1. Reserve capacity explicitly. If median interrupt load is 18%, plan new feature work to roughly 80% of median throughput.
  2. Agree intake rules. Who can add work mid-sprint, and what leaves when it does?
  3. Rotate interrupt duty. One engineer per sprint absorbs support and urgent bugs so the rest of the team keeps focus.
  4. Fix the source. A persistently high bug share points at quality practices; a high support share at documentation, tooling or ownership boundaries.

Questions to ask

  • How much work routinely enters after sprint planning?
  • Are feature commitments adjusted when production work appears?
  • How much capacity should be reserved for bug fixes and support?

Example

A sprint started with 50 points committed. During the sprint, 15 points were added: 6 points of bugs, 4 points of support investigations, 2 points of an emergency fix and 3 points of a planned story split. Total handled: 65 points. Added-work load: 15 ÷ 65 = 23%. Bugs, support and emergencies alone: 12 ÷ 65 = 18%.

Across six sprints the median interrupt load was 19%. The team reserved 10 points per sprint for interrupts, rotated support duty weekly, and stopped counting the story split as an interruption by refining stories before planning.

Related metrics and how the Workload & Carryover report helps

See it on your own data in the Workload & carryover report.

Related: planned vs unplanned work, sprint scope creep, engineering work mix and why work carries over.

The Workload & Carryover report calculates added-work load for every sprint, splits it into emergency, bug, support, planned scope and unknown, and only calls it interrupt load when the data supports it. The category mapping is editable and stays in your browser.

Frequently asked questions

What is a good interrupt load for an engineering team?
There is no universal target. Under about 10% is quiet; 10–20% is common for teams that own production. What matters is planning to your own measured level rather than assuming zero.
Is interrupt load the same as unplanned work?
Close, but not identical. Unplanned work is usually measured on completed work; interrupt load is measured on everything handled, and separates true interruptions (bugs, support, emergencies) from planned scope that arrived late.