The vote was three weeks ago. Fists of five went up around the room, the scope was trimmed until the team believed in it, and a release date went on the roadmap with everyone’s name behind it. That commitment was expert engineering judgment — the people closest to the work, validating the scope, the dependencies, and the capacity as they stood that day.
Then Tuesday happened. A production incident swallowed two engineers for four days. Wednesday brought an expedite for a strategic customer that couldn’t wait. Thursday, an escaped defect from the last release came home to roost. Nobody left the team. Nothing on the release board changed. But the capacity behind that committed date quietly did.
Unplanned work is capacity change in disguise
Of the three things that erode a committed release date — scope creep, dependencies surfaced too late, and capacity changes — capacity erodes in two distinct ways. The visible way is people: a resignation, a mid-increment reassignment, a new hire still ramping up. That side has its own playbook in Capacity Risk: The Third Thing That Erodes a Committed Release Date.
The quieter way is unplanned work: incidents, expedites, escaped defects, and the steady drip of “quick favors” that consume the team’s hours without ever touching the release backlog. It is harder to see precisely because nothing visible changes. Headcount is stable. Standup happens. The board still shows the same issues in the same columns. Every stolen hour was logged somewhere else — against the incident, the support queue, the other team’s board — so the release plan never feels the loss until the burnup flattens and someone asks why.
The vote wasn’t wrong. It was a snapshot.
Here is the part most retrospectives get backwards: the team’s confidence vote already accounted for unplanned work — at its historical level. A forecast built on real delivered throughput has last quarter’s incidents, interrupts, and support load priced in, because that noise is part of the throughput the team actually achieved. The vote wasn’t optimism, and it wasn’t guesswork. It was the team’s considered judgment on the evidence available that day.
What the vote could not include is the spike it hadn’t seen yet — the incident-heavy month, the surprise compliance request, the expedite season. A snapshot, however expert, can’t defend itself against what arrives after it’s taken. That isn’t a flaw in the team’s judgment. It’s a property of snapshots.
From a snapshot to a live reading
The answer isn’t to re-vote every week, and it isn’t to pad the plan until no spike can hurt it. It’s to keep the team’s commitment current as the data moves. Release planning in Jira with a live forecast runs the team’s real throughput through a Monte Carlo simulation — thousands of trials, refreshed as the data changes — and carries the committed date with its confidence band: 50%, 85%, 95%.
When a week of throughput disappears into unplanned work, the next forecast reflects it, and the drift shows up in days against the committed date. Not a feeling that “we’re getting hammered lately,” but a number: the date the team committed at 85% confidence now sits six days later than it did two weeks ago. The team still owns every assumption — which throughput window to trust, whose capacity counts, what’s in scope. The app just does the arithmetic at a scale no spreadsheet can, and never lets the answer go stale.
Renegotiate before the slip, not after
The reading turns unplanned work from an excuse into an early warning. On-track means the committed date still holds at the 85% line. When erosion pushes it into the amber zone, that’s the moment to act — while options still exist: shed or reassign the interrupt load, trim scope at the cut-line, or renegotiate the date openly with weeks of runway instead of confessing a slip at the demo.
A sensible sprint capacity buffer absorbs the normal level of interruption — that’s what it’s for. What a buffer can’t do is tell you when it has been blown through. A live committed date can, and it tells you in the only unit executives actually hear: days.
Make the invisible work visible
Unplanned work will keep coming; that’s not a process failure, it’s software. The failure mode is letting it erode a committed date silently for six weeks. Keep the team’s expert judgment at the center, keep the forecast live behind it, and the Tuesday-morning incident becomes a data point you manage — not a surprise you apologize for.
See how Advanced Release Planning keeps your committed date honest — try it free on your own Jira data, or read how capacity change tracking works in the docs.
Leave a Reply
Your email is safe with us.