Why Estimates Are Wrong (and Why That's Not the Point)

Why human estimates miss

Three structural reasons.

The planning fallacy. Humans systematically underestimate task duration because they take an 'inside view' — imagining the specific case in front of them and forgetting the base rate of how similar work has actually gone (Kahneman and Tversky 1977). The bias is robust: in one study, people finished only about a third of their projects by the time they had confidently predicted, and knowing their own history of lateness did not fix it (Buehler, Griffin and Ross 1994). Experience reduces some error, but the review evidence on whether seniority reliably improves estimates is mixed (Halkjelsvik and Jørgensen 2012) — the optimistic bias is not eliminated by experience.

The political pricing. In any organization where estimates are treated as commitments, the smart move is to inflate them. The cost of overrunning a tight estimate is real; the cost of finishing early on a loose one is negligible. Over time, the estimates the system collects are not predictions at all — they are insurance bids.

The context starvation. The person estimating usually does not have the full context. They are looking at a one-line task description and reaching into memory for similar work. Their memory is selective; their similar work was usually slightly different. The estimate is biased by whichever similar task is most recent or most vivid.

Here is the part most teams get backwards. Because all three biases push the same way — toward optimism — the error is a systematic bias, not random noise, so it does not cancel out when tasks are summed. Empirical reviews put the typical software effort overrun near 30% (Moløkken-Østvold 2004; Jørgensen and Gruschke 2009), and Flyvbjerg's analysis of 5,392 IT projects found that aggregate overruns follow a fat-tailed power-law distribution — extreme overruns are far more common than a bell curve would predict. Rolling many task estimates up into a project total inherits the bias and the tail risk rather than averaging them away (Flyvbjerg et al. 2022). A project is not safer than its tasks because it has more of them; it is exposed to their combined optimism.

Prediction vs. commitment vs. budget

An estimate gets used three different ways, often by three different people simultaneously, often without anyone realizing the conflict.

As a prediction: 'this will probably take 3 hours.' The output is a best guess about reality. The right rebuttal is data ('similar tasks have taken 5 hours on average').

As a commitment: 'I will deliver this in 3 hours.' The output is a promise. The right rebuttal is push-back about scope or capacity ('I can't promise that without dropping X').

As a budget: 'we will spend at most 3 hours on this before reassessing.' The output is a constraint on the work, not on reality. The right rebuttal is about value ('is 3 hours the right ceiling given how much this matters?').

Most team conflict around estimates comes from one person using the number as a budget while another treats it as a commitment. The cure is to be explicit about which use the estimate is serving in any given moment. Kavanah surfaces all three: the agent's estimate is a prediction; the team's accepted estimate is a budget; the assigned member's stated estimate (if they choose to add one) is a soft commitment.

Distributions, not points

A single number is the wrong shape for an estimate. The right shape is a distribution: 'median 3 hours, p90 5 hours, p99 8 hours.' The shape captures something the point estimate hides — how uncertain the estimate is.

A task with median 3 / p90 4 is well-understood; the team can plan around it. A task with median 3 / p90 9 is poorly understood; the team should not plan around it without breaking it down further. Same median, completely different planning implication.

Kavanah's task-intelligence layer produces distribution-shaped estimates by default. The UI displays the median prominently and the p90 alongside it as a confidence band. Where the band is wide, the manager has two good responses: tighten the description (which feeds the model more signal) or break the task into smaller pieces (which moves each piece into a tighter band).

The practical effect is that planning conversations stop being 'is your estimate right' and become 'is this work well-enough understood to plan around.' Those are different conversations and the second is more useful.

What estimates are actually for

Three uses justify the effort of producing estimates at all.

Sequencing. If task A is estimated 1 day and task B is estimated 5 days, that affects which goes first if both share an assignee or a dependency. The estimate does not need to be accurate; it just needs to be comparable.

Commitment to outside parties. If you tell a customer they will have the feature in two weeks, you need an estimate, however lossy, behind that promise. Kavanah's project-level estimates roll up from task estimates and surface in the Portfolio view.

Capacity planning. If your team has 40 person-hours this week and the proposed work is estimated at 60 person-hours, you need to know that before the week starts. The estimate is the input.

Notice what is missing from this list: performance evaluation. Estimates are not a fair input to whether someone is performing well. They are too noisy and too easily gamed. If you use them that way, the gaming will dominate the signal within a quarter. Module 6 covers what actually belongs in the people-metrics column.