Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Unplanned work takes capacity away from planned work and makes sprint forecasts less reliable. No published study or Scrum guidance gives a universal percentage of budget or capacity that it consumes, so the “budget killer” label is a hook rather than a measured figure. What your team can measure is its own exposure: the hours that unplanned requests actually took, the planned work they displaced, and the labor cost of those hours at a rate your organization chooses. This guide explains how to build that picture and how to read it.
Why unplanned work is a forecasting problem first
Scrum does not promise that a sprint will stay untouched. The 2017 edition of the Scrum Guide describes sprint planning as using projected capacity and past performance to forecast what the Developers can accomplish, and it allows scope to be negotiated with the Product Owner as work unfolds. Check the current Scrum Guide for present wording, because the normative text may have changed since 2017. Scrum.org’s practitioner article “How to Handle Unplanned Work in Scrum” states the reality plainly: “No matter how much a Scrum Team plans, there are times when someone asks them to undertake unplanned work mid-Sprint.”
The problem, then, is not that interruptions happen. It is that they happen without being seen, sized, or traded off against planned commitments. A team that cannot say how many hours went to unplanned requests cannot explain why its forecast missed.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteDefine unplanned work before you count it
A count is only comparable across sprints if everyone uses the same definition. A workable one is: any work that was not in the Sprint Backlog when the sprint began and that arrives mid-sprint. Common categories include:
#1 Best Overall
- Production support and incident response
- Defects found after the sprint started
- Urgent requests from customers or from other departments
- Dependencies that block planned items
- Newly discovered work, such as a story that turns out to need a larger change
Keep two kinds of effect apart. The direct effort is the time spent on the unplanned item itself. The indirect effects are interruption and resumption costs, such as the time needed to return to a half-finished task. Count direct effort as a number when you have it. Record indirect effects as a number only if the team actually measures them; otherwise note them qualitatively, so the total does not look more precise than it is.
How to measure your exposure
- Agree on the definition at sprint planning. Write down what counts as unplanned work and what does not, and keep that wording for the whole sprint.
- Open a work log with one row per item. Use the fields in the table below. A spreadsheet or a tagged work-management board is enough.
- Record effort in hours. Use actual hours where people log time. Where you only have estimates, mark them as estimates in their own column.
- Choose a denominator and keep it fixed. A common choice is the team’s available hours for the sprint, after time off and known fixed commitments are removed. Write the formula into the log so later sprints use it too.
- Calculate the share at sprint review. Divide unplanned hours by available hours, and report the result alongside the count of requests.
- Record what moved. Note which planned items slipped, by how much, and whether the Sprint Goal was affected.
- Compare at least three sprints before drawing conclusions. A single sprint shows an event; several sprints show a pattern and its variability.
| Field | What to capture | Why it matters |
|---|---|---|
| Arrival date | When the request entered the sprint | Shows whether demand clusters early or late |
| Source | Who asked: support, another department, a customer, an internal stakeholder | Shows where demand originates and who needs a conversation |
| Category | Production support, defect, urgent customer request, dependency, or newly discovered work | Separates recurring demand from one-off events |
| Urgency | A team-defined scale, such as must-handle-now or can-wait | Determines whether the item can go through normal ordering |
| Effort | Hours spent, marked as actual or estimate | The core number for exposure |
| Decision | Added, deferred, rejected, or exchanged for planned work | Makes the trade-off visible |
| Displaced work | Which planned items moved, and by how much | Captures the cost that hours alone do not show |
| Sprint Goal effect | None, at risk, or changed | Links interruptions to outcomes the stakeholders care about |
Turning hours into a direct cost
Once hours are recorded, a transparent direct-cost estimate is:
Direct cost = recorded unplanned-work hours × the fully loaded hourly labor cost your organization selects
State the cost basis (how the loaded rate was built) and the period it covers. This is a calculation the organization makes for its own planning. It is not a standard Scrum metric, and story points cannot stand in for hours in it.
The figures below are hypothetical and exist only to show the arithmetic. They are not benchmarks. Suppose a five-person team works two-week sprints of 80 available hours per person, so 400 hours per sprint and 1,200 across three sprints. Over those three sprints it logs 36 hours of unplanned work. Its finance function’s fully loaded rate is 85 per hour.
- Observed share of available effort: 36 ÷ 1,200 = 3.0% across the three sprints
- Direct cost: 36 × 85 = 3,060 over the same period
This figure leaves out displaced work. If a planned feature slipped by a week because of the same interruptions, its value to the business may be larger or smaller than the labor cost, and the log is where that trade-off is recorded.
Rank #3
What the studies say about interruptions
Two peer-reviewed or case-based studies describe how interruptions arise in Scrum-style teams. Neither gives a rate that can be applied elsewhere.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Wiesche (2021): mechanisms in four teams
Manuel Wiesche’s article “Interruptions in Agile Software Development Teams,” published in the Project Management Journal in 2021, reports an exploratory study of four agile software-development teams. Its analysis identifies three groups of interruption: programming-related work impediments, interaction-related interruptions, and interruptions imposed by the external environment. The abstract reports that the teams managed these through improved information retrieval and reduced team dependencies. Use the study to describe the mechanisms that drive interruptions. Four teams cannot establish how often interruptions occur or how much they cost in general.
Tanner and Mackinnon (2015): a South African Scrum case
Maureen Tanner and Angela Mackinnon’s study, “Sources of Interruptions Experienced During a Scrum Sprint,” appeared in the Electronic Journal of Information Systems Evaluation in 2015. It identifies urgent ad hoc requests from users in other departments as a source of interruption, and it finds that weak interdepartmental communication delayed work. The authors state that such requests could hinder sprint progress. These are findings from one case, so they indicate which sources to look for in your own log, not how large each source will be.
Choosing a response
Scrum.org’s guidance describes several options a team can weigh, and the team decides which ones to use and adapts as it learns. The options are not mutually exclusive, but each has a different trade-off.
| Option | Fits when | Trade-off |
|---|---|---|
| Hold a capacity allowance | Demand is steady enough to forecast from past sprints | Idle capacity when demand is low |
| Add accepted work to the Sprint Backlog | The team wants full visibility and the volume of items is moderate | Every item must be tracked, which adds overhead |
| Limit work in progress | The team can finish current items before switching | Urgent items may wait, so the team needs an explicit expedite path |
| Use a separate support team | Support work is significant and frequent | Adds headcount and coordination between teams |
| Renegotiate scope with the Product Owner | An urgent request must be accepted but the Sprint Goal still has to hold | Planned items are removed, so the log must name what moved |
| Defer or reject into the backlog | The request can wait for ordering and a future sprint | Requesters may need to be told that their item will wait |
When comparing these, ask six questions: how urgent the requests are, how frequent and variable they are, how much tracking overhead the team can carry, whether current work can be finished before switching, who owns recurring support, and which planned outcome moves if a request is accepted.
Sizing a capacity buffer from your own history
Scrum.org suggests estimating likely demand from prior performance and its variability, then leaving some capacity free. Kenneth S. Rubin’s Essential Scrum: A Practical Guide to the Most Popular Agile Process describes capacity as what remains after other Scrum activities, work outside the sprint, time off, and organizational overhead are subtracted. Rubin advises that buffer size can be set empirically after several sprints. Check the chapter on sprint planning in the current edition for the full discussion.
Best Value
A practical method is to take the unplanned hours per sprint from your log, look at the typical value and the high end of the last six sprints, and set the allowance between them. Review the figure each quarter, because demand can change when a product, customer base, or support process changes.
What to state when you report the numbers
- The definition of unplanned work used, and any category left out
- Whether each hour is an actual or an estimate
- The denominator and how it was calculated
- The loaded rate, its cost basis, and the period covered
- Which planned items moved, and whether the Sprint Goal was affected
- The number of sprints in the sample
A report that includes these points lets readers see what the figure does and does not cover, and it lets the team compare its own sprints over time.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
