Estimating Software Work: Why Every Method Fails, and What to Do
Key takeaway
Estimate in ranges, not single numbers, and derive them from how long comparable work actually took rather than from imagining the happy path. Then track the ratio between estimated and actual over time — that ratio is the most useful planning input any team can have.
Software estimates are systematically optimistic, and knowing this doesn't fix it. What does help is changing what you produce: a range with stated assumptions is honest and useful, where a single confident number is neither.
Why estimates go wrong
- We estimate the work we can imagine, and most of the time goes to the parts nobody imagined — the integration that behaves differently, the edge case, the data that isn't as described.
- Estimates ignore interruption, review, testing, deployment, and the meetings surrounding all of it.
- Optimism is social: people estimate the version of events where nothing goes wrong, particularly when a stakeholder is hoping for a number.
- Comparable past work is rarely consulted, though it's the single best predictor available.
Methods, and what each is for
- Relative sizing (story points) — good for comparing items within a team's own backlog; meaningless across teams and useless to stakeholders as a date.
- Hours — communicates directly to the business, and invites false precision. Use ranges.
- Reference-class estimating — find three similar past pieces of work and use their actual durations. The most accurate approach available to most teams, and the least used.
- Breaking work down — decomposition improves accuracy more than any technique, and anything that can't be broken below a few days is a research task, not an estimate.
Communicate uncertainty honestly
Give a range with a confidence level and the assumptions it rests on: "eight to fourteen weeks, assuming the payment provider's sandbox is available in week one and the data we've been shown is representative." Named assumptions turn a later slip into a shared, traceable event rather than a broken promise — and they often prompt the stakeholder to remove the risk themselves.
Improve over time
- Record estimates and actuals. Most teams discover a fairly stable multiplier, and applying it is more honest than pretending the next estimate will be different.
- Re-estimate at phase boundaries, when you know far more than at the start.
- Time-box research and prototypes instead of estimating them — you cannot estimate work whose difficulty is the unknown.
- For anything beyond a few months, plan on scope flexibility rather than date precision. Fixing scope, date, and quality simultaneously is the promise that produces the late-night rewrite.