Software estimation is a topic that engineers and executives tend to argue about from opposite sides of a wall. Engineers say estimates are guesses dressed up as numbers. Executives say estimates are commitments the business runs on. Both positions are defensible, and both are missing the point.
Good estimation is not about producing a more accurate number. It is about producing a useful number — one that the business can plan around, with an honest expression of uncertainty, and a stated plan for what happens when reality deviates. Hourly estimates fail at this, and they fail for reasons that are now well understood.
Why hourly estimates are wrong for a reason
The classic approach — break the work into tasks, estimate each task in hours, add them up, maybe add a small buffer — is almost always wrong. Not occasionally wrong. Systematically wrong in the same direction, for structural reasons.
The first reason is optimism bias. Engineers estimate from the inside view: “I understand this task, I can see the shape of the solution, here is how long it will take.” The inside view consistently ignores the things that will go wrong, because by definition the things that will go wrong are the things not yet anticipated. Research on this goes back decades and is not seriously contested.
The second reason is novelty. Most software work that is worth estimating is work the team has not done exactly before. If it had, it would be a template or an automated task. Novel work has unknown unknowns, and those unknowns are exactly what eats the hours.
The third reason is integration surprise. Individual tasks can be estimated with some accuracy. The cost of fitting those tasks together — resolving conflicts, handling edge cases at interfaces, testing end-to-end — is what the task-level view misses. The sum of well-estimated parts is not a well-estimated whole.
The compound effect of these three forces is that bottom-up task estimates, without correction, run roughly fifty to one hundred percent low on non-trivial projects. This is not a pessimism claim. It is what the data shows.
Reference-class forecasting
The alternative is what Daniel Kahneman and others have called reference-class forecasting, and it is the single biggest improvement most teams can make to their estimation practice.
Instead of estimating from first principles — how long should this take, given the tasks involved — you look at similar projects you or the industry have done, and you estimate based on how long those took. The reference class is not the exact same project. It is projects with similar scope, similar integration surface, similar novelty profile, and similar team composition.
The practical method: name three to five past projects that the current one resembles. Write down how long each took, including the overruns. Then estimate the current project by asking: is there any strong reason this should be faster or slower than the average of those? Usually there is not — and when engineers say there is, the reason is often “we have learned from last time,” which is worth at most twenty percent.
The reference-class estimate will almost always be significantly higher than the task-level estimate. That is not pessimism. It is the task-level estimate being wrong for the reasons described above, and the reference-class estimate being corrected by empirical data.
The cone of uncertainty
Any useful estimate comes with an uncertainty range. A single number is a false promise. A range lets the business plan around the reality that the work will finish somewhere inside it.
The cone of uncertainty is a useful mental model. At the start of a project, before requirements are clarified and before technical discovery has happened, the uncertainty range is roughly four-to-one — the project could take anywhere from a quarter to four times the initial estimate. As the project progresses and uncertainty resolves, the cone narrows. By the time half the work is done, the range is typically down to about two-to-one. Only near the end is the range tight enough to treat the estimate as a firm number.
This matters for how estimates should be communicated. A single-number estimate at the start of a project is wrong by construction. A range, explicitly labeled with its current uncertainty, is honest. Executives who have been trained on single-number estimates sometimes push back on ranges, but a good ranged estimate is more useful to them than a precise-looking number that turns out to be wrong by ninety percent.
Buffers: project-level, not task-level
A common instinct is to add a buffer to every task — pad each estimate by twenty percent, say. This does not work, for a predictable reason.
Per-task buffers get absorbed. Engineers unconsciously treat the padded estimate as the real estimate, and slow down to fill the available time. The buffer does not actually exist as a resource that can be redeployed when something unexpected happens.
Project-level buffers work better. Estimate tasks without padding. Then add a buffer at the project level — ten to thirty percent of the total, held centrally. When a specific task overruns because of a genuine surprise, the buffer is drawn down to cover it. When tasks come in on time, the buffer is preserved for the inevitable future surprise.
This approach has two advantages. It resists Parkinson’s law — tasks do not expand to fill padding they cannot see. And it makes the buffer a visible management resource, not a hidden one, so depletion of the buffer is an early warning signal that the project is in trouble.
Communicating uncertainty to non-engineers
Executives usually want a date. Giving them a range can feel like dodging the question. The translation that works is to distinguish between a commitment and a forecast.
A forecast is “the project is most likely to finish in May, with a range of April to July.” That is what engineering can honestly produce early on. A commitment is “we will deliver by the end of Q2, and if we cannot, we will escalate and replan.” That is what the business needs to plan around.
The commitment is a weaker statement than the forecast — it does not say exactly when the project finishes, just sets a bound and a trigger for what happens if the bound is threatened. That weaker statement is usually more useful to executives than a false-precision date, because it tells them what to watch and when to get involved.
A good project leader translates between these registers fluently. Inside the team: ranges, probabilities, risks. Outside the team: commitments, thresholds, escalation triggers. Both are necessary.
When to replan, and when to push
The final piece most estimation practices get wrong is what to do when reality deviates from the plan.
A small overrun — say, one task took twenty percent longer — is not a signal to replan. It is a signal that the buffer is being used as designed. The project continues.
A structural overrun — the first milestone is fifty percent late, the team is consistently estimating short, the scope keeps growing — is a signal to stop and replan. Not to push harder. Not to add people. To sit down, look at what the current data says the project actually takes, and produce a new estimate based on observed velocity rather than the original guess.
The instinct in corporate environments is to treat replanning as failure. That instinct is wrong. The failure is continuing to work to a plan that the data has already disproved. Replanning based on evidence is how projects stay connected to reality. Pushing harder against a broken plan is how projects quietly miss by six months.
The estimate, in the end, is less important than what the team does with the variance between the estimate and reality. A team that estimates imperfectly but replans honestly delivers more reliably than a team that estimates precisely and ignores the variance. Get that relationship right, and estimation becomes a useful tool. Get it wrong, and no estimation method will save the project.
Top comments (0)