Software estimates are probability distributions, not promises. Use three point estimation, reference class forecasting and confidence intervals to stop missing dates.
I once told our CEO a feature would ship "in about two weeks." It shipped in five. I wasn't sandbagging, I wasn't lazy, and I wasn't lying — at least not on purpose. But the number was wrong the second it left my mouth, because I took a fat, messy probability distribution, crushed it into one confident-sounding date, and pretended that date was a thing I could hand over.
That is the entire problem, in one sentence. A software estimate is a bet on an uncertain future. We collect these bets, staple them to a Gantt chart, and pass them up to leadership as if they were promises. Then we act shocked when reality — which never agreed to any of this — shows up to collect. Six years of shipping Flutter apps and a few years running a small engineering team in Dubai have knocked the fight out of me on this one. Here's how I estimate now, and how I talk about estimates without volunteering to be the villain later.
If you've ever wondered why your sprint planning keeps producing delivery dates that quietly evaporate, or why "how long will this take?" is the question that most reliably makes you feel like a liar, this is the mental model that fixed it for me.
Walk back through the numbers you gave over the last three months. "Two days." "End of the sprint." "We can have it out before the demo." Now the uncomfortable question: how many of those carried a silent "…if nothing goes wrong" clause you never said out loud?
That clause does all the work. When I say "two days," what I actually mean — if I'm honest — is: two days if the API behaves, if requirements don't shift, if I don't get yanked into a production incident, if the design is final, if the thing I assumed was cached is actually cached. I'm quoting the best-case path and presenting it as the expected path. Those are different numbers, and the gap between them is where projects quietly go to die.
The dishonesty isn't moral, it's structural. I was asked for one number, so I gave one number. But the true answer was never a number. It was a shape — a spread of outcomes at different likelihoods. The moment I flattened that shape into a point, I threw away the single most useful thing I knew: how unsure I actually was. That discarded uncertainty is the exact information a project manager needs to plan around risk, and I deleted it before it ever reached them.
Humans are bad at this in a boringly predictable way. We picture the version of the task where everything goes to plan, estimate that, and quietly assume the plan holds. Then we do it again on the next task, having apparently learned nothing from the last one that ran long. Psychologists call this the planning fallacy, and you don't need a study to believe it. You need a git log. Go look at how long your last five "quick" tasks actually took versus what you first said.
Single-number estimation culture makes it worse in a specific, mechanical way. When a PM asks "how long?" and you say "three days," three things fire at once:
I watched this compound on a project a couple of years back. Every task got a tidy single-day number. The sprint plan summed them and produced a beautiful, precise, entirely fictional delivery date. Each estimate was "reasonable" on its own. Together they assumed nothing across twelve tasks would go sideways — roughly the odds of flipping twelve heads in a row. We missed by about 60%. Not because anyone was incompetent, but because we added up twelve best-cases and called the sum a plan.
This is the part that gets underestimated: estimation error doesn't cancel out across a project, it accumulates. One task running long doesn't get rescued by another running short, because the short ones were already priced at their best case. A plan built from single-number estimates is a plan that only works if every bet lands — and that's not how bets work.
The fix starts with a mindset shift that sounds pedantic and is actually the whole game: stop trying to estimate the right number. Start estimating the range of numbers. This is the core of three-point estimation, and it's the single cheapest upgrade you can make to how your team quotes work.
When I size a task now, I make myself answer three questions instead of one:
For a task where my gut barks "three days," the honest answer is often: best 2, likely 4, bad 9. Look at that spread. The distance from 4 to 9 isn't noise — it's the signal. It's telling me this task has real uncertainty living inside it, usually an integration or a requirement I don't understand yet.
The three-number habit does something a single number never can: it makes my uncertainty visible, to me and to everyone downstream. A tight range (best 3, likely 4, bad 5) says "I've done this before, I trust it." A wide range (best 2, likely 4, bad 12) says "there's a landmine in here and I don't know where." Those two tasks can share a "likely" number of 4 and still deserve completely different treatment. The single-number world can't tell them apart. The range world can't hide the difference.
If you want a bit more rigor, weight the three points. The rough expected value I run in my head is a classic three-point (PERT-style) estimate:
expected ≈ (best + 4 × likely + worst) / 6
So for best 2, likely 4, bad 9, the expected value lands at about (2 + 16 + 9) / 6 ≈ 4.5 days — pulled off the fantasy best-case and toward the middle of the distribution, which is exactly where a single number should sit if someone insists on one. It's crude, not a dissertation, and I'd never present the decimal as if it were meaningful. But it stops me from anchoring the whole conversation on the number I most want to be true.
The wide part of the range almost always traces back to one of a few usual suspects. Naming them turns a vague "this feels risky" into something you can act on:
If none of those apply, the range should be tight and you should be suspicious if it isn't. If one or more apply, the range should be wide, and pretending otherwise is just relocating the surprise to later.
Here's the part most engineers skip: the range only helps if you actually communicate it. Computing a private distribution and then reporting the midpoint as a clean date defeats the whole exercise. You have to speak the uncertainty out loud, in words a PM can act on.
The pattern I use is a range, plus an explicit confidence level, plus the biggest risk:
"I'm about 80% confident this lands in 4 to 6 days. The main risk is the payments integration — if their sandbox behaves like last time, it could stretch to 9. Want me to spike that first to tighten the estimate?"
Notice what that sentence does. It gives a usable range instead of false precision. It attaches a confidence number so nobody hears "6 days" as a blood oath. It names the specific thing that could blow the range, turning a vague worry into a decision. And it offers a lever: spend a little time now to shrink the uncertainty.
Confidence language is the underrated half of this. There's a real, communicable difference between:
A good PM does completely different things with those three sentences. Feed them all "Friday" and you've stolen their ability to manage risk. Part of my job is protecting my PM's decisions, and I can't do that if I launder my uncertainty into one tidy date before it ever reaches them.
One more habit: quote confidence intervals, not deadlines, and re-quote them as you learn. Day one, I might be 60% confident in a 4-to-8 range. After a spike kills the scary unknown, I'm 85% confident in 4-to-5. The estimate tightening over time is a feature, not an embarrassment. It shows the team the fog is lifting, and it's far more honest than pretending I had 4-to-5 precision on day one. In practice I treat every estimate as a live number with a timestamp, not a commitment carved on day zero.
Your intuition about a task is optimistic. It is optimistic every single time, and knowing you're biased doesn't make you unbiased — awareness is not a cure. So I've mostly stopped trusting the inside view (imagining this task from scratch) and lean hard on the outside view: how long did tasks like this actually take, historically?
This is reference-class forecasting, and it's the single highest-leverage estimation upgrade I've made. Instead of "how long will this auth screen take," I ask "how long did the last four auth screens take?" The answer is sitting in your issue tracker, and it's almost always longer than your gut claims.
On our team, concretely:
A concrete case from our stack: any task that touches a new third-party integration reliably takes 1.5x to 2x whatever the engineer first guesses. Every time. I've watched it with payment SDKs, with an analytics vendor whose "5-minute" setup ate a full day on iOS entitlements, with a shipping-rates API that turned out to paginate in a way nobody documented. So now when someone says "the analytics SDK is a two-day job," we don't argue about their two days. We check the reference class, quietly pencil in four, and plan around that. Nobody's being a pessimist. We're just refusing to bet that this integration will be the one that finally goes smoothly.
The beautiful thing about the outside view is that it needs almost no discipline to start. You don't need a formal database or story-point calibration ceremony. You need a habit of glancing at "what did the last few of these cost us" before you open your mouth. Even a rough reference class beats a confident guess.
Here's the reframe that took me years to swallow: the most powerful thing you control isn't the estimate, it's the scope. Time is mostly a function of how much you're building. If the range is too wide or the date too far out, the honest lever is almost never "work faster." It's "build less."
When leadership pushes on a timeline, arguing about the estimate is a losing game — you're defending a probability distribution against someone who wants a promise. Reframe it as a scope conversation and you're suddenly on the same side of the table:
"The full feature is a 4-to-6 day bet. But the core flow — the 80% users actually touch — is a 2-day bet I'm 90% confident in. We ship that Thursday and fast-follow the edge cases. Which do you want?"
That hands the tradeoff to the person who owns the priorities, where it belongs. Now they're choosing between confident-and-small versus complete-and-uncertain — a real business decision — instead of pressuring me to shrink a number by wishing at it.
Scope is also the fastest way to collapse uncertainty. A wide range usually means a big, fuzzy chunk of work with unknowns baked in. Slice it thin and the unknowns get cornered. Each small piece is easier to estimate and easier to reference against past work. "Rebuild the profile screen" is a two-week guess with error bars you could drive a truck through. Broken into eight tickets, most are near-certain and the risk concentrates into one or two — which is exactly where your attention should have been anyway. Decomposition isn't just project hygiene; it's an estimation technique, because small tasks have narrower distributions than big ones.
All of this is lovely until a director says: "I don't want a range. I need a date for the board." Fair. Sometimes the business genuinely needs a committed date, and lecturing them about probability distributions is a great way to be right and useless at the same time. The move is to give them a date and the price of that date.
A committed date is just a point on a distribution. Choosing one means picking a confidence level and being honest about the cost:
The goal isn't to dodge commitment. I commit to dates constantly. The goal is that when I hand over a date, everyone knows exactly what confidence level they bought, and what it cost in buffer or scope to get it. A committed date with a stated confidence and a named risk is a professional artifact. A committed date pulled from thin air to end an uncomfortable meeting is a liability with a due date.
(best + 4×likely + worst) / 6 if you want a single number.