Ask a developer how long a feature will take and you will get one number. That number is a lie — not because developers are dishonest, but because a single number cannot carry uncertainty. Ask for a range instead and you get a shrug: “two to six weeks” tells the business nothing it can plan around.
The method I use on every estimate is three numbers: optimistic (everything goes right), likely (normal friction), and worst-case (the API documentation is wrong, the client is slow with content, someone gets sick). Writing down the worst case is the valuable part — it forces you to name the risks while there is still time to reduce them.
Then commit to the likely number externally and track against the optimistic one internally. The gap between them is your management buffer, and it is visible instead of hidden inside padded line items. When a sponsor asks why the estimate is four weeks and not three, you can point at the named risks instead of defending a feeling.
The free project estimator on this site is built on the same idea: it gives you a range, not a promise, because a tool that pretends certainty is worse than no tool at all. Use it to open the conversation, then do the three-number exercise on the real scope.
Why a single number is always wrong
An estimate is a forecast, and every forecast has a spread. A single number collapses that spread to a point — and the point everyone remembers afterwards is the one that suited the plan, not the one you actually meant. Say four weeks in a meeting and it becomes a commitment before the meeting ends.
The range is not hedging. It is the honest shape of what you know. A developer who says two to six weeks is not being evasive; they are telling you the work has real uncertainty in it. The problem is that a bare range gives the business nothing to plan around, which is why it gets pushed back until someone picks a number anyway.
Where the three numbers come from
The optimistic figure is the one most of us give by default, because it is the one we can picture. It assumes the API behaves as documented, the design is final, the content exists, and nobody gets pulled onto something urgent halfway through. It is rarely a lie; it is just the happy path.
The likely figure comes from comparison, not intuition. Take the optimistic number and hold it against the last two or three similar pieces of work. What actually happened? Something usually did. Normal friction — a round of feedback you forgot to budget, an environment that needed fixing before you could deploy — is not bad luck. It is the ordinary condition of the work.
The worst case is the number worth the most, and the one people skip. It is not a pessimism exercise. Write it down and immediately name what would cause it: undocumented third-party behaviour, a dependency on someone outside the team, content arriving late. That list is the real output of the estimate.
What the gap is actually for
The distance between optimistic and likely is your management buffer, and the point of the method is that it sits in the open rather than hidden inside padded line items. Padding works until someone asks why a two-day task is quoted at five, and then it costs you credibility you needed for the difficult conversation later.
Commit to the likely number externally. Track against the optimistic one internally. If you are running to the optimistic figure by week two, you have room. If you have already spent the buffer, you know in week two rather than the night before launch.
How to present it without losing the room
Lead with the likely number, because that is the one the business needs. Then show the named risks behind the worst case, and what each would cost. This changes the conversation from a negotiation about your estimate into a discussion about their risk tolerance — which is where it belongs.
When a sponsor asks why it is four weeks and not three, you are not defending a feeling. You are pointing at three specific risks and asking which of them they would like to remove. Often they can remove one, and the estimate genuinely comes down.
When the worst case actually arrives
Sometimes it does, and this is where the method earns its keep. You named that risk in writing before the work started. The conversation is not an apology; it is a reference back to a decision everybody made with their eyes open. Projects rarely fail because something went wrong. They fail because something went wrong that nobody had admitted was possible.
The habit that makes it improve
Record what actually happened against what you estimated. Not to grade yourself — to calibrate. After a handful of projects you will find your optimistic numbers are consistently off by a familiar factor, and that factor is more useful than any estimation formula. Estimating is a skill that improves only if you close the loop.
