Three weeks ago the team said the release was ninety percent done. Last week it was ninety percent done. This morning, in standup, it is ninety percent done — and the launch date is nine days out.

Nobody in that room is lying. That is the uncomfortable part.

The joke that keeps being right

The ninety-ninety rule is credited to Tom Cargill of Bell Labs and was published by Jon Bentley in his Programming Pearls column in Communications of the ACM in September 1985: “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

The percentages add up to 180. That is the joke. It has survived four decades because every engineer has lived it: the integration that only bites when both sides are real, the edge case that turns out to be a design decision, the last defect that is architectural rather than local. The work that remains at the end is not a scaled-down version of the work that came before. It is a different kind of work, and it arrives with less room to absorb it.

Your team’s judgment wasn’t the problem

It is tempting to read the rule as evidence that engineers are bad at estimating. That reading is wrong, and acting on it makes planning worse.

When a room of professional engineers raises a fist of five, that vote is the most honest signal in the increment. It reflects what was knowable on planning day: the scope as agreed, the dependencies as mapped, the team as staffed. The vote is expert judgment, and it is usually right about the day it was taken.

A confidence vote is a snapshot. The problem is not the snapshot. The problem is that the increment keeps moving after the hands go down, and by the final stretch the plan the team voted on and the plan they are actually executing have drifted apart.

Why erosion concentrates in the last 10%

The three things that erode a release date — scope creep, dependencies surfaced too late, and capacity changes — do not distribute themselves evenly across the increment. They pile up at the end.

Scope returns as rework. Work marked done under a loose Definition of Done comes back in the final weeks as bugs, missing tests, or documentation nobody scheduled. To the forecast it is indistinguishable from new scope: it is simply more remaining work.

Dependencies finally get exercised. A hard link to another team is theoretical until the day you integrate. That day is usually near the end, which is exactly when there is no slack left to resequence around it.

Capacity quietly leaves. The final stretch competes with production incidents, release logistics, and the people already being pulled onto whatever comes next. The vote assumed a team that is no longer entirely present.

Percent-complete is the wrong instrument

Here is why “ninety percent done” can stay true for a month without anyone misreporting. Percent-complete has a denominator, and the denominator moves. If a release grows from 100 issues to 120 while 90 are finished, reported completion drops from 90% to 75% without a single piece of work being undone. Run that in reverse and a team can clear real work for three weeks while the number sits still.

A ratio that both scope and progress can move is not a schedule instrument. The honest question is not “what fraction is finished” but “how much work is actually left, and how fast is this team clearing work like it right now.” That is the same reason a release burndown can say you’re on track while the committed date disagrees, and the same reason a hardening sprint is buffer the vote already priced rather than time you get back.

What it looks like in Jira

This is the job Release Management, Roadmaps, Portfolio PPM & Timeline does. It does not re-run the confidence vote with better math or replace the team’s judgment. The team still owns the assumptions: which throughput window to trust, whose capacity is genuinely in, what is really in scope. The app does the arithmetic at Monte Carlo scale and keeps it current.

Instead of a completion percentage, you get a committed date carried with its confidence — June 7 at 85%, say — sitting on a band the whole room can read. Because the forecast reads remaining work rather than reported progress, a release stuck in its last stretch produces a date that stops improving. Rework returning from Done and scope added after the commitment both land in the same measure. The gap between the forecast and the committed date shows up in days, in week two, while pulling scope back across the cut-line or resequencing a dependency is still a real option.

You cannot repeal the ninety-ninety rule. You can stop it from working in the dark. See it on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio