The plan review goes well. The work is broken down, the risks have been named, the team votes, and everyone in the room believes the date. Everyone has also been in this exact room before — watching a date that felt just as solid quietly slip. Daniel Kahneman and Amos Tversky gave that pattern a name in 1979: the planning fallacy. We forecast work from the inside, walking the happy path step by step, even when our own history says the happy path is rare.
Kahneman’s favorite example was his own. A team he joined to write a decision-making curriculum estimated about two years to finish. Then he asked how long comparable teams had actually taken: the ones that finished at all had needed seven to ten years. The inside view said two. The track record said seven-plus. The book took eight.
The fallacy is not in your team’s judgment
Here is the part most retellings get wrong: the planning fallacy is not evidence that engineers can’t estimate. A team’s confidence vote at the end of PI Planning — the fist of five — is expert engineering judgment, and it is usually right about the things it can see: the shape of the work, the items that carry real risk, who is already stretched thin.
The fallacy lives in what happens next. That judgment gets compressed into a single naked date. The assumptions behind it — which throughput history, whose capacity, what exactly is in scope — go unrecorded. And the date is never re-checked against evidence. The failure is not the vote; it is asking expert judgment to also do the job of an instrument.
The outside view, built into the forecast
Kahneman’s corrective is called the outside view: stop asking “how will this project go?” and ask “how do projects like this one usually go?” Forecast from the track record of a reference class, then adjust. Bent Flyvbjerg later operationalized the idea as reference-class forecasting, now used on major public projects in several countries.
For a software release, the honest reference class is already sitting in Jira: your team’s actual completed throughput, sprint over sprint. Release Management, Roadmaps & Product Portfolio for Jira runs Monte Carlo simulation over that history — thousands of simulated deliveries of the remaining scope, each one sampling what your team has really done — and returns a committed date carried on a 50/85/95% confidence band.
The team still owns every assumption that matters: which throughput window is representative, whose capacity counts, and what is in scope — how the forecast chooses its data is a team decision, not a black box. The app owns the arithmetic, at a scale no planning meeting can reach by hand. Nothing about this replaces the confidence vote. It gives the vote an evidence base: the SAFe confidence vote, run on data the team validates.
The fallacy doesn’t retire at commitment
The planning fallacy is usually told as a planning-day story. It is not one. It returns every time someone says “we can absorb that” — when a stakeholder adds one reasonable request, when a blocking dependency surfaces late, when a teammate is pulled to another initiative. Each of those is a fresh inside-view forecast, made in seconds, in a hallway.
That is post-commitment erosion, and it arrives from exactly three directions: scope creep, dependencies surfaced too late, and capacity changes — the three things that erode a committed release date. None of them announces itself as a slip. Each quietly rewrites the assumptions the vote was built on, the same way private padding hides inside individual estimates.
So the outside view has to stay switched on. The app recalculates the band continuously from observed throughput and tracks all three drivers against the committed date, in days. A commitment made at 85% that has drifted to 62% becomes visible while there is still time to renegotiate scope or move the date deliberately — because the cone of uncertainty narrows on evidence, not on the passage of time.
What changes in the room
Teams that put an outside view next to their committed date describe the same shift: the conversation stops being about defending a number and starts being about reading an instrument. “Are we still at 85% for November 14?” is a question with a current answer. If yes, keep shipping. If no, the drivers are named in days — scope grew the date by six, a capacity change took four — and the renegotiation happens with evidence on the table, before the slip.
Kahneman never argued that experts should stop judging. He argued that judgment deserves a base rate. Your team’s confidence vote deserves the same.
Give your next committed date an outside view
Run a probabilistic forecast on a real Fix Version with Release Management, Roadmaps & Product Portfolio for Jira. Pick the throughput window, set the scope, and see what your own track record says about the date on the board — at 50, 85, and 95% confidence.
Leave a Reply
Your email is safe with us.