Planned vs Unplanned Engineering Work: How to Measure It Honestly

Definitions

Planned work is work that was in the sprint when it started (allowing a short grace period for planning to finish). Unplanned work is work added after the sprint started.

The classification is about timing, not type. A bug the team chose at planning is planned work. A feature request that a stakeholder pushed in on day three is unplanned. Classifying all bugs as unplanned is a common and misleading shortcut.

Why it matters

Unplanned work explains a large share of missed commitments. If 25% of completed work arrived mid-sprint, a plan that filled 100% of typical throughput with planned work could not have succeeded, however hard the team worked.

Measuring it also changes planning conversations: instead of promising to “protect the sprint”, teams can reserve explicit room based on how much unplanned work usually arrives.

How to calculate planned vs unplanned work

Unplanned completed = completed issues added after sprint start + grace period
Planned completed   = completed issues present at sprint start
Unplanned share     = unplanned completed ÷ total completed

This needs sprint start dates. With the Sprint field’s change history you get exact add times. With only Created dates you get a minimum: issues created after sprint start were certainly added later, but an older issue pulled in mid-sprint looks planned.

The planning grace period

Sprint planning rarely finishes at the exact minute the sprint starts. Items added in the first hours are usually the tail end of planning, not interruptions. A grace period — for example 24 hours after sprint start — keeps those items in the planned bucket. Make the grace period explicit and configurable so the classification rule is visible, and keep it short: a week-long grace period would hide real mid-sprint intake.

Unplanned work that was not finished

The unplanned share of *completed* work understates the disruption. Work added mid-sprint that was not finished still consumed attention — triage, investigation, context switching — and it usually carries into the next sprint, where it becomes carryover. Look at scope added (finished or not) alongside the unplanned share of completed work.

How to interpret the share

• Under ~10%: planning is holding; small buffers suffice.
• 10–25%: common; reserve explicit room rather than filling the sprint.
• Over 25%, consistently: intake is effectively uncontrolled; the sprint plan is a suggestion.
• Look at what the unplanned work is. Support requests, incidents and stakeholder asks need different responses; use issue types and labels to group them.

Trend matters more than any single sprint. One sprint with a production incident will spike the unplanned share; a share that creeps up over five sprints signals that intake rules have loosened or that operational load is growing.

Common mistakes

• Assuming bug = unplanned. Many bugs are deliberately planned.
• Ignoring unplanned work that was not completed. It still consumed attention; look at scope added, not only completed.
• Treating a minimum as exact. Without Sprint history, say “at least”.
• Blaming individuals for interruptions. Unplanned work reflects intake policy, not personal focus.

Leadership implications and questions to ask

Leaders decide who can add work to a sprint and what leaves when something enters. A visible, agreed buffer for unplanned work is more honest than a sprint that pretends to be protected.

Questions engineering managers should ask

• Who can add work mid-sprint, and is there an agreed buffer for it?
• What kind of unplanned work is most common — incidents, support, stakeholder requests?
• When work enters, what leaves?
• Should planned capacity explicitly reserve room for maintenance and defect work?

Example

A sprint completed 52 points. 41 points were in the sprint at start (including three planned bug fixes); 11 points were added after start — three support investigations and two urgent bugs. Unplanned share: 21%. Over six sprints the average was 19%, so the team now plans new work to about 80% of median throughput and reviews the buffer monthly.

Related metrics and how the Capacity & Commitment report helps

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

Related: sprint scope creep, engineering capacity planning and the scope change view.

The Capacity & Commitment report splits completed work into planned and unplanned by when it entered the sprint, shows the trend across sprints, and groups completed work into configurable categories (feature, bug, technical debt, support, operational) without assuming any type is unplanned.

Frequently asked questions

Are bugs unplanned work?

Not automatically. A bug chosen at sprint planning is planned. Unplanned work is defined by when it entered the sprint, not by its type.

Can I measure unplanned work from a Jira CSV?

With sprint dates, yes — as a minimum based on Created dates. Exact measurement needs the Sprint field change history.

Related guides

• Sprint scope creep

  How to measure sprint scope creep from Jira — original commitment, added, removed, net growth — why CSV exports undercount it, and how engineering managers can control it.

• Engineering capacity planning

  A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.

• Sprint capacity

  A step-by-step method for calculating sprint capacity from historical throughput: median delivery, existing WIP, room for unplanned work, and why hour-based capacity formulas overcommit teams.

• Why sprints fail

  The recurring, measurable reasons sprints miss their commitments — over-commitment, scope creep, review and QA queues, release backlogs, dependencies, unclear requirements — and how to tell them apart with data.