Most estimation problems are not math problems. They are confidence problems. You are asked “how long will this take?” about work you have never done in exactly this form, and a single number feels like a lie the moment you say it. This article shows you how to produce estimates you can defend: using ranges instead of points, anchoring to past work, and separating the estimate from the deadline. You will end with a small routine you can run in ten minutes.
Why a single-number estimate almost always fails
A point estimate (“three days”) hides everything useful. It doesn’t say whether you are 50% sure or 90% sure. It doesn’t reveal the assumptions underneath. When you commit to one number, you are secretly betting that nothing goes wrong, that requirements are stable, and that you understood the task fully. Software and creative work rarely cooperate.
The deeper cause is that estimation blends two different things: how much effort the work needs, and how much you actually know about the work. Early on, uncertainty dominates. A number pretends that uncertainty away, which is why estimates given at the start of a project are the ones that hurt most.
Estimate a range, then narrow it
Instead of one number, give three: a best case, a likely case, and a worst case. This forces you to think about what could go wrong, not just the happy path. A rough weighted average leans toward the likely case while respecting the tail: something like (best + 4×likely + worst) ÷ 6. This is the classic three-point approach used in PERT, and it is useful precisely because it makes the spread visible.
The width of the range is itself information. A tight range (2 to 3 days) says you understand the work. A wide range (2 to 10 days) says you don’t yet, and that the honest next step is investigation, not commitment.
Anchor to real reference points
The single strongest estimation tool is memory of similar work. Before guessing, ask: what is the most similar thing I have finished, and how long did it actually take? Not how long you thought it would take then. How long it really took. Reference-based estimating beats gut feeling because it quietly includes the interruptions, reviews, and rework that abstract reasoning forgets.
Separate the estimate from the deadline
An estimate is a prediction. A deadline is a commitment. They are different objects, and collapsing them corrupts both. When someone hears “about a week” and writes “due Friday,” the honest prediction has been turned into a promise you never made. State clearly which one you are giving. If pressed for a date, give the date that corresponds to your worst case, not your likely case, because that is the number you can actually stand behind.
A real scenario
A developer is asked to “add export to PDF.” Gut says two days. Using ranges: best case one day (a library does the work), likely three days (formatting and edge cases), worst case eight days (the data model doesn’t map cleanly to pages). Weighted: (1 + 12 + 8) ÷ 6 ≈ 3.5 days, with a wide spread. That spread triggers a two-hour spike to test the library first. The spike reveals pagination is hard, collapsing the range to 4 to 6 days. The team now plans against a real number instead of a hopeful one.
Common mistakes and how to fix them
- Estimating only the coding, not the whole task. Fix: include review, testing, deployment, and the meeting where someone changes their mind. These are part of “done.”
- Padding silently. Doubling your number in secret destroys trust and teaches others to double it again. Fix: show the range and the assumptions openly instead of hiding a buffer.
- Treating estimates as fixed. An estimate made with 10% knowledge should be revised at 50% knowledge. Fix: re-estimate at natural checkpoints and communicate the change early.
- Ignoring your own history. If your estimates are consistently half of reality, that ratio is data. Fix: track a few past tasks and apply your personal correction factor.
A ten-minute estimation routine
- Write the task in one sentence, including what “done” means.
- Recall the most similar finished task and its real duration.
- Write best, likely, and worst case.
- Compute the weighted estimate and note the spread.
- If the spread is wide, schedule a short spike instead of committing.
- State clearly whether you are giving an estimate or a date.
- Record the actual time later, so next time is sharper.
Conclusion and next step
Good estimates are not about being right the first time. They are about being honest about what you know and updating as you learn. Your next step is small: on your current task, replace your single number with a three-point range and write down the one assumption most likely to break. That habit alone will change how the rest of your project plans.
FAQ
How do I estimate something I’ve never done before?
Break it into the smallest part you can actually reason about, estimate that, and treat the rest as explicit unknown. Then run a short timeboxed spike on the riskiest piece to convert guesswork into knowledge before committing.
Should I share my worst-case number with stakeholders?
Yes, but frame it as the confident date. People handle ranges better than a surprise slip. Give the likely case as the plan and the worst case as the commitment.
What if I’m always pressured to lower my estimate?
Lowering the number does not lower the work. Respond by adjusting scope, not the estimate: ask what could be cut to hit the desired date. This keeps the conversation honest.
How often should I re-estimate?
Whenever your knowledge meaningfully changes: after a spike, after requirements shift, or at any planning checkpoint. Re-estimating is a sign of discipline, not failure.
References
- Steve McConnell, Software Estimation: Demystifying the Black Art — a widely respected practitioner reference on ranges and uncertainty.