Engineering estimates are wrong. They’ve always been wrong. The interesting question isn’t “how do we get them right” (you don’t) but “how do we communicate uncertainty so the business can plan around it.”
Single-number estimates — “two weeks” — pretend uncertainty away. Three-number estimates expose it. The change is small; the downstream effect on roadmap planning, OKRs, and trust is large.
Why one-number estimates fail
The moment you say “two weeks,” three things happen:
- The PM puts it in the roadmap as a deadline
- The sales team commits a customer to that delivery date
- You internally feel you can’t come back and revise it
None of these involve a conversation about confidence. The number gets treated as certain because there’s no shape around it to suggest otherwise.
The reality is that real engineering outcomes follow a heavily right-skewed distribution. There’s a floor (the work CAN’T be done in less than X); there’s a peak (the most likely outcome); there’s a long tail (the unexpected goes one way — longer).
The three-number estimate
For any task larger than a day, give three numbers:
- Best case (10th percentile).Everything goes right. No blockers. No production fires. The dependency works first try. “Best case” is not “optimistic.” It’s “here’s the floor you can’t go below.”
- Likely (50th percentile).The realistic plan with a couple of unknowns that you’ll hit but solve. This is the number you’d bet your OWN money on, in private.
- Worst case (90th percentile).The plan when several unknowns turn out to be hard. NOT “everything fails.” The 90% line.
Communicate all three. Let the business pick which one they want to use for which purpose. Sales should quote customers off the worst case. Roadmaps should be built off the likely. Stretch ambitions can ride on the best case.
Why this works
Single-number estimates trigger a planning fallacy — the brain locks onto the number and defends it. Three-number estimates trigger a planning conversation — the gap between best and worst makes uncertainty visible, and the business responds by building in buffer where buffer is needed.
The bonus: tracking your three-number estimates against actuals teaches you about your own estimation bias. Most engineers’ “worst case” is closer to the median than the 90th percentile. You’ll learn this within a quarter and recalibrate.
Common objections (and the answers)
- “PMs hate three numbers; they want one.” PMs who want one number, against your three, are asking you to hide uncertainty. Educate them. The good ones get it within a week.
- “Worst case feels like sandbagging.” Worst case is your honest 90th percentile, not your padding. If your team is sandbagging, the fix is calibration, not eliminating the number.
- “We’ll always get held to the worst case.” Only if you let it become a deadline. Communicate the likely as the planning number; the worst case is the “don’t commit to a customer before” number.
For roadmap-level work, use ranges of weeks
Multi-quarter initiatives can’t be estimated in days. Use ranges: “6-10 weeks if things go well; 12-16 if not.” The same principle: communicate uncertainty in the size of the range, not the average of the range.
How we approach this
Every project we kick off through SaaS Product Development gets estimated in three-number form. The proposal we send has best, likely and worst case — not a single committed number. Customers find it counterintuitive at first; six months in they tell us it’s the most useful thing in our entire process.
Takeaways
- Single-number estimates pretend certainty. They’re always wrong.
- Three numbers: 10th, 50th, 90th percentile. Best · likely · worst.
- Sales quotes off worst. Roadmap plans off likely. Ambitions ride on best.
- Track actuals against estimates. Recalibrate quarterly.
