Recommended Free Tools
You can measure how much unplanned work costs your agile team, but only with your own data. No published source gives a universal percentage of capacity or budget lost to unplanned work, so any figure you see quoted as a standard should be treated with suspicion. What you can do is log each unplanned item with its effort, record what it displaced, and convert the hours into a share of capacity and, if you choose, a direct labor cost. This article walks through that calculation, explains which parts are well supported by evidence and which are not, and outlines how teams have responded when unplanned demand is frequent.
What counts as unplanned work
Unplanned work is any effort that was not in the sprint plan when the sprint started and that the team takes on during the sprint. Examples include production support, defects found late, urgent requests from other departments, dependencies that block planned items, and newly discovered work. The category matters because each type has a different cause and a different fix.
As an Amazon Associate I earn from qualifying purchases.
Keep two things separate. The first is the direct effort: the hours spent on the unplanned item itself. The second is the indirect effect: the time lost when someone is interrupted, switches context, and must resume planned work. Interruption costs are real in the studies discussed below, but unless your team records them, do not add them to your totals. Report them as a qualitative concern or as a separate, clearly labeled estimate.
What to record for each item
A lightweight work log is enough. Use one row per unplanned item and keep the definition of “unplanned” the same for the whole period you measure.
#1 Best Overall
- Arrival date and time, so you can see when during the sprint demand arrived.
- Request source, such as a customer, another department, the support queue, or an internal engineer.
- Category: production support, defect, urgent customer request, dependency, or newly discovered work.
- Urgency, agreed in advance, for example “must start today” or “can wait for the next sprint”.
- Estimated and actual effort, in hours. Do not use story points for this, because they are not hours and do not work as an accounting measure.
- Disposition: added to the sprint, deferred, rejected, or exchanged for a planned item.
- Planned work displaced: the sprint backlog items that did not finish, or were pushed out, because of this item.
Keep planned and unplanned effort in separate columns in team reporting. If they are mixed, the team cannot see how much of its capacity went to demand it did not plan.
How to calculate your exposure
- Define the capacity denominator. Choose one basis and apply it consistently, for example available developer hours per sprint after known time off and meetings you have decided to count. Write the definition down so it does not change between sprints.
- Total the unplanned hours for the same sprints from your log.
- Calculate the share of capacity. Unplanned share (%) = unplanned hours ÷ available hours × 100. Calculate it per sprint and across several sprints, then look at the spread, not just the average.
- Count the displaced planned work. List the planned items that did not finish because of unplanned work, and note their size in the team’s own units.
- Estimate direct labor cost if you need a dollar figure. Direct cost = unplanned hours × the fully loaded hourly labor rate you choose. State the cost basis (which roles, which rate method) and the period. This is an internal accounting calculation, not a standard Scrum metric.
- Compare forecasts with outcomes. Note how much the sprint forecast changed after the unplanned work arrived and whether the team’s next forecast accounted for it.
Illustrative example (hypothetical numbers)
The figures below are invented to show the arithmetic. They are not a benchmark. Suppose a five-person team has 10 working days in a two-week sprint, with six productive hours per person per day. Available capacity is 5 × 10 × 6 = 300 hours. The team logs 45 hours of unplanned work, which is 15% of available hours. Two planned items of roughly 12 hours each were pushed to the next sprint. If the blended fully loaded rate is $85 per hour, the direct cost of the 45 hours is $3,825 for that sprint. Repeat the calculation over several sprints before drawing any conclusion, because one sprint can be unusual.
Share of capacity and forecast variance
The share of capacity tells you how much of the team’s time was spent outside the plan. Forecast variance tells you how well the plan survived contact with reality. Track both. A team can have a modest unplanned share and still miss its forecasts often if demand is highly variable, and a team with a high share may forecast well if that share is stable and it has planned for it.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the sources establish
Scrum guidance on forecasts
The 2017 edition of the Scrum Guide states that projected capacity and past performance inform sprint planning, that the Developers select the work they forecast they can complete, and that scope can be negotiated with the Product Owner as work unfolds. Scrum planning is therefore a forecast, not a promise that nothing will change mid-sprint. The Scrum Guide has been revised since 2017, so check the current edition for normative wording before quoting it.
Rank #3
Scrum.org practitioner guidance
Scrum.org’s practitioner article “How to Handle Unplanned Work in Scrum” states: “No matter how much a Scrum Team plans, there are times when someone asks them to undertake unplanned work mid-Sprint.” It describes several options a team can consider: estimate likely demand from prior performance and its variability, leave some capacity free, make accepted work visible, limit work in progress, or consider a separate team for significant and frequent support work. The article presents these as options for the team to decide and adapt, not as binding rules. Scrum.org also recommends adding accepted incoming work to the Sprint Backlog when that is the team’s chosen approach.
Interruptions in agile teams
Manuel Wiesche’s 2021 article “Interruptions in Agile Software Development Teams,” published in the Project Management Journal, reports an exploratory study of four agile software-development teams. It identifies three groups of interruptions: programming-related work impediments, interaction-related interruptions, and interruptions imposed by the external environment. The abstract reports that the teams managed these through better information retrieval and reduced dependencies between team members. Because the sample is four teams, the study describes mechanisms. It does not establish how often interruptions happen or what they cost in general.
Sources of interruptions in a Scrum sprint
Maureen Tanner and Angela Mackinnon’s 2015 case study, “Sources of Interruptions Experienced During a Scrum Sprint,” in the Electronic Journal of Information Systems Evaluation, examines a South African Scrum team. It identifies urgent ad hoc requests from users in other departments and weak communication between departments as sources of disruption. The authors state that such requests could hinder sprint progress and that poor interdepartmental communication delayed work. These are findings from one case, so they show what can happen, not how common it is.
Crashes, 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 minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCapacity and buffers
Kenneth S. Rubin’s Essential Scrum: A Practical Guide to the Most Popular Agile Process describes sprint capacity as what remains after accounting for other Scrum activities, work outside the sprint, time off, and organizational overhead. It advises that a buffer can be sized empirically after several sprints of data. This is practical guidance from a book, not a mandated percentage, and it is a useful reference if you want to see how capacity is built up from the bottom.
Best Value
Choosing a response
Once you know your exposure, compare the response options against the questions below. The right answer depends on your context, and teams often combine several options.
| Question | Lean toward this when… | Trade-off to watch |
|---|---|---|
| Is the demand urgent? | Requests must be handled the same day | Urgent handling can break a sprint commitment unless an expedite path is agreed |
| Is the demand steady or volatile? | Steady demand can be forecast and given a planned allowance | Volatile demand needs a larger buffer or a separate team, and buffers can look like idle time |
| Should each item be visible? | Items are significant, so they go into the Sprint Backlog as accepted work | Many small tasks can overwhelm the board, so track them through another agreed mechanism |
| Can current work finish first? | Work in progress is limited and finishing is possible | Stopping current work to start new work adds switching costs that the log may not show |
| Who should own recurring support? | Support is occasional and the whole team can absorb it with a capacity allowance | A separate support team adds headcount and coordination with the Developers |
| Can scope move? | The Product Owner can renegotiate scope while protecting the Sprint Goal | Accepting a request moves a planned outcome, and that outcome should be named explicitly |
Where the numbers stop
The sources do not establish a universal percentage of capacity lost to unplanned work, a universal share of agile-team budgets, or a universal financial loss rate for interruptions. The studies cited above are small or case-based, and the practitioner guidance is advisory. A dollar figure from your own log is only as good as the hours recorded and the labor-rate basis you choose. Treat any figure you calculate as a local estimate, and report the method alongside it.
Where to start
Begin with two or three sprints of logging using the fields above. Calculate the unplanned share and the displaced planned work for each sprint. Use the spread across sprints to decide whether to add a planned allowance, change how requests are accepted, or consider a separate support arrangement. The aim is to make the trade-off visible to the team and to the people who set its priorities, so that unplanned demand is discussed with numbers rather than as a surprise each sprint.
Further reading: Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process, sprint-planning chapter, covers non-sprint work, interruptions and empirically sized buffers.
Quoted sources: Scrum.org, “How to Handle Unplanned Work in Scrum”; The Scrum Guide (2017); Manuel Wiesche, “Interruptions in Agile Software Development Teams,” Project Management Journal (2021); Maureen Tanner and Angela Mackinnon, “Sources of Interruptions Experienced During a Scrum Sprint,” Electronic Journal of Information Systems Evaluation (2015); Kenneth S. Rubin, Essential Scrum.
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.
