Estimating without lying: ranges, confidence, and the buffer talk
ost project estimates are wrong, but the bad ones are wrong in predictable ways: too low, too confident, and presented as a single number that turns into a deadline. Honest estimating doesn't mean being a pessimist — it means giving the people who depend on your number enough information to make real decisions.
Honest project estimates
- Honest estimatingprefer
- Use rangesnot
- State confidence
- Avoid single numbers
- Break work downestimate
- Concrete pieces
- Discuss bufferselse
- Unbuffered becomes deadline
Table of Contents
Quick reference
Range, not number
Quote a range with a confidence level. Single numbers become deadlines.
Three-point estimate
Best case, expected, worst case. For larger projects.
Break it down
Estimate 5–15 chunks, sum expected values, then add buffer.
Buffer 20–30%
For integration, review, testing, surprises. Named explicitly.
Don't sum worst cases
Worst cases don't correlate. The project worst case is smaller than the sum.
Buffer talk
Tell stakeholders the optimistic case and the planning case separately.
Most project estimates are wrong, but the bad ones are wrong in predictable ways: too low, too confident, and presented as a single number that turns into a deadline. Honest estimating doesn't mean being a pessimist — it means giving the people who depend on your number enough information to make real decisions.
What you'll learn
Ranges and confidence beat single numbers
When someone asks "how long will this take?", the worst answer is "three weeks." Single numbers feel decisive; they're also almost always wrong, and they get treated as commitments.
A better answer: "Three to five weeks. I'm maybe 70% confident in that range." This communicates three things a single number doesn't:
For longer projects, structure the estimate as three numbers: best case, expected, worst case. Best case assumes nothing surprises you. Expected is what you'd bet money on. Worst case assumes one or two specific things go wrong.
The stakeholder who actually needs your number can usually use this directly. The one who insists on a single number is the one most likely to be unhappy when the single number turns out to be wrong.
Break the work down before you estimate
The single most reliable improvement to estimates is breaking the work down before you estimate. Top-of-mind estimates rely on a vague mental model of the project; broken-down estimates rely on a list of concrete pieces, each of which you can size more honestly.
A workable breakdown:
- 1List the chunks. Five to fifteen pieces of work that, summed, deliver the project. Not tasks — chunks, each two days to two weeks.
- 2Estimate each chunk as a range or three-point estimate.
- 3Sum the expected values, but don't sum the worst cases. Worst cases don't correlate; the project worst case is rarely the sum of the chunk worst cases.
- 4Add an explicit buffer for integration, testing, code review, and the unforeseen — typically 20–30% of the expected total.
- 5Identify the riskiest chunk and ask whether de-risking it first would shrink the variance of the whole project.
The breakdown surfaces hidden chunks (deployment, migrations, third-party integrations) that single-number estimates skip. Those skipped chunks are the source of most overruns.
The buffer conversation
Honest buffered plan
Fragile unbuffered promise
Buffers are real. Pretending they aren't — quoting an unbuffered estimate to make stakeholders happy — is dishonest, and the unbuffered estimate becomes the deadline that gets missed.
The healthier conversation:
"Based on the chunks, I'd expect this to take four weeks if everything goes smoothly. Realistically, with code review, testing, integration, and the inevitable surprises, I'd plan against six weeks. If you need to commit to a date publicly, I'd commit to the six-week date."
This works because it:
If the response is "can you do it in four weeks?", the honest answer is usually "I can if nothing surprises us, but I wouldn't bet on it. What needs to be true for the four-week date to be safer?" That's a real conversation. The fake conversation — agreeing to four weeks anyway — ends in a missed date and lost credibility.
Want a more guided way to practise this?
Common questions
What if I genuinely don't know enough to estimate?
Say so, and propose a time-boxed investigation. "I can't estimate this responsibly without two days of investigation. Let me do that, then I'll come back with a real range." Most stakeholders will agree; the ones who won't are setting you up to fail anyway.
How do I handle stakeholders who only want a single number?
Give them the high end of the range as the "single number," and explain that's what you'd commit to publicly. They get the simplicity they want; you get the buffer you need.
Should I add buffer per task or at the end?
At the end. Per-task buffers tend to compound silently and produce estimates that are wildly conservative. A single named buffer at the end is more honest and easier to defend.
What about Agile / story points?
Story points work well for relative sizing within a team that's calibrated. They translate poorly to dates with stakeholders who don't share the team's calibration. For external commitments, convert to ranges and confidence levels.
Bottom line
Honest estimates use ranges, not single numbers; break the work into chunks before estimating; add a named buffer of 20–30%; and have the buffer conversation openly with stakeholders. Single-number estimates feel decisive but produce missed dates. Ranges with confidence produce trusted teams.