Deciding

Planning fallacy

People predict their own projects will finish sooner than similar projects ever have.

Forecasts about one's own tasks are systematically optimistic about duration and cost, even when the forecaster knows their past projects overran. The cause is that people build the estimate from a plan for this specific case and ignore the distribution of outcomes for similar cases. Knowing about the bias does not remove it, but changing the input class does.

Inside view against outside view

An inside-view estimate is built from a plan for this project. An outside-view estimate starts from how long comparable projects actually took. The gap between them is the planning fallacy, and the fix is to change the input rather than to add a buffer. The values here are illustrative of the shape; the overrun ratio differs by project type and should come from your own history.

How it shows up in software

Sprint estimates, launch dates, and migration timelines all run on inside-view reasoning. The team imagines the happy path, adds a buffer, and ignores that the last four projects of this shape took twice the plan. It compounds through dependencies: each team's optimistic estimate becomes another team's assumed input, and the error multiplies rather than averaging out.

Using it well

Keep a record of past estimates against actuals by project type, and start every new estimate from that ratio.
Estimate in ranges with a stated confidence, and commit externally to the pessimistic end of the range.
Run a pre-mortem: assume the project shipped six months late and write down why, before the estimate is locked.
Distinguish honest optimism from incentive. If a team is rewarded for an aggressive date, you have a policy problem, not a cognitive one.

Where it turns manipulative

Using the bias as a reason to publicly pad every estimate while privately planning to the original date sets the team up for the overrun you claimed to avoid.
Telling customers a feature is 'coming soon' on the basis of an inside-view estimate turns a forecast error into a broken promise.
Citing the planning fallacy to dismiss an engineer's warning. The fallacy runs toward optimism, so a pessimistic estimate is usually evidence, not bias.

Where you have seen it

Linear
Cycle views show scope changes and completion trends over past cycles alongside the current one.
Jira
Velocity and burndown charts report historical completed points per sprint next to the current commitment.
GitHub
Milestones show open and closed issue counts over time rather than only a target date.

What the research says

Buehler, Griffin and Ross, 1994Well evidenced
Students predicted when they would finish their theses. Even their worst-case estimates were beaten by the actual completion times for a large share of the group, and their best guesses were substantially early.
Kahneman and Tversky, 1979Well evidenced
Introduced the inside view and outside view distinction, prescribing reference class forecasting: estimate from the distribution of comparable past projects rather than from a plan for this one.
Flyvbjerg, 2006 onwardWell evidenced
Large databases of transport and infrastructure megaprojects show persistent cost overruns and demand shortfalls across decades and countries, and reference class forecasting is now mandated in some public appraisal guidance.
Flyvbjerg argues much of megaproject overrun is strategic misrepresentation (bidding low to win approval) rather than honest optimism. Both mechanisms produce the same overrun, and they need different fixes.

Grades are a judgement about the evidence, not about how useful the idea is. Plenty of contested effects are still worth knowing, as long as you do not cite them as settled.