Interruption Cost
Interruption Cost estimates how much developer time is lost to unplanned work, context switching, and reactive interruptions. It helps quantify the impact of unscheduled tasks that displace planned sprint work and reduce delivery focus.
Calculation
Interruption Cost is based on a tiered system of interruption severity. Each type of interruption is associated with a multiplier that estimates its disruptive impact:
- Ticket-level interruptions: A new ticket is started before completing a planned task (e.g., 50% cost)
- Sprint-level interruptions: Planned work is paused or delayed in favor of unplanned work (e.g., 25% cost)
- Emergency interruptions: Urgent production incidents or after-hours pages (e.g., 100%+ cost)
The metric is calculated as the sum of weighted interruptions divided by total planned effort:
interruption cost = (sum of ticket weights × multiplier) ÷ planned sprint effort
Goals
Interruption Cost helps teams understand how much delivery capacity is being consumed by unplanned or high-disruption work. It answers questions like:
- Are urgent tasks pulling developers away from planned priorities?
- What percentage of our sprint capacity is being lost to context switching?
- Can we better manage intake and triage to protect focus?
Quantifying interruption overhead makes it easier to balance responsiveness with delivery. It turns what was once a vague frustration into actionable insight.
Variations
Interruption Cost may also be referred to as Interruption Tax, Context Switching Overhead, or Reactive Work Cost. Variations include:
- By interruption level – ticket, sprint, emergency
- By severity, such as P1 vs. P3 incidents
- By department or function, e.g. support vs. engineering
- By time period, such as per sprint or monthly trend
- Normalized per team or developer, to surface imbalance
Some teams also compare interruption cost to Planning Accuracy or Sprint Rollover Rate to see how it affects delivery outcomes.
Limitations
Interruption Cost uses multipliers to estimate disruption, which are directional but not exact. The metric does not capture subtler losses like attention residue, nor does it distinguish between avoidable and unavoidable interrupts.
Use this metric as a planning and prioritization signal, not as an individual performance metric.
To get a fuller picture of how interruptions affect delivery, pair it with:
| Complementary Metric | Why It’s Relevant |
|---|---|
| Sprint Scope Creep | Shows whether mid-sprint work additions correlate with increased interruption load |
| Work in Progress (WIP) | Reveals if context switching is compounding fragmentation and blocking focus |
| Lead Time for Changes | Indicates whether interruptions are delaying overall delivery velocity |
Optimization
Reducing Interruption Cost requires minimizing both the frequency and severity of disruptions—and shielding teams from unnecessary reactive work.
- Establish clear triage channels. Route inbound work requests or support tickets through a structured intake process, not ad hoc interruptions
- Assign rotating responders. Use on-call rotations or triage leads to isolate interruption handling from developers focused on sprint work
- Set sprint guardrails. Avoid re-prioritizing work mid-sprint unless genuinely urgent, and clearly label reactive tickets for later analysis
- Quantify the tradeoffs. Track how much capacity is lost and whether interrupted work is carried over, dropped, or delayed
- Address root causes of reactive work. Analyze patterns in urgent tickets to prevent common problems at the source
Interruption Cost gives teams visibility into what often goes unmeasured: the drag of distraction. When managed intentionally, it helps teams protect their time, and deliver on what they planned to build.
