The team says two weeks. Leadership hears two weeks, and someone puts it in an email to a customer. The feature ships in five, and everyone is a little disappointed, including the engineers, who believed the number when they gave it.
The usual response is to fix the estimates: more detailed breakdowns, a padding factor, another planning meeting. We think that misreads the problem. Engineering estimation is a prediction about work nobody has done yet, and most of the error comes from what the team couldn't know when it made the guess. More process mostly produces more confident wrong numbers. Teams that deliver predictably get their estimates wrong too. What they do differently is handle the uncertainty openly.
Why software estimates are wrong
There are three causes, and effort isn't one of them.
You know least at the start. Steve McConnell's Software Estimation (2006) gives the cone of uncertainty its standard software form: estimates are least accurate when work begins and narrow as the work is discovered. At the earliest stage, his ranges run from a quarter of the eventual figure to four times it. The cone only narrows if somebody does the discovering. Uncertainty that nobody examines stays as wide as it was.
The hidden work. Writing the code is often the smaller part of the job. Integration, edge cases, review rounds, the flaky test suite, the payments API whose documentation stops halfway: this is where the weeks go, and almost none of it is visible when the estimate is made.
The planning fallacy. Daniel Kahneman and Amos Tversky described it in 1979. People predicting how long a task will take underestimate it, even when they know similar tasks overran, because they reason from the case in front of them instead of from how comparable cases went. Engineers picture the happy path because it's the one they can picture, and asking them to try harder leaves the bias where it was.
Treat these as properties of the work and the job changes. You stop hunting for a better number and start managing what the number can't tell you.
What to do instead
Give ranges
"Five days" sounds precise and rarely is. "Three to eight days, most likely five, assuming the auth service doesn't need changes" says how confident you are and what would move the number. Write the two or three assumptions beside any estimate longer than a few days. When one turns out wrong, everyone can see why the range moved.
Spike the fuzziest part first
If a piece of work is too vague to estimate, that tells you something. Before committing to a date, spend a time-boxed day or two on the part nobody understands, with a defined question and a fixed end. A spike that narrows "two to eight weeks" to "three to four" is the most useful planning you'll do that quarter.
Forecast from history
Cycle time, how long work took from start to done, is a practical version of what Kahneman and Tversky called the outside view: forecasting from comparable cases instead of from hope. If your team's stories take between three and ten days whatever their estimate said, that spread is your planning data.
Two cautions. History predicts only work that resembles the past, so novel work still needs a spike. And a cycle-time distribution is itself a range, so quoting its average as a date brings the original mistake straight back.
Slice smaller
Small pieces estimate better, and their errors compound less. Donald Reinertsen's The Principles of Product Development Flow makes the wider case: smaller batches and less work in progress make delivery more predictable than pressure does. A team working in one- or two-day slices sees a slip in its first week. A team carrying one six-week item finds out in week five.
Telling stakeholders
Most of the damage happens in translation, when a careful range reaches someone who needed a date.
- Keep the estimate and the commitment apart, and say both. "Our best estimate is late May. What we'll commit to is mid-June." The gap is your buffer, and naming it stops it looking like padding.
- Don't let a range turn into a deadline by accident. Say "three to eight days" and somebody will write down three. Tell them which number to plan against.
- Re-forecast the week you know. When something moves the timeline, tell people while they still have options: a later date, less scope, or more help added early enough to count. Fred Brooks's observation in The Mythical Man-Month, that adding people to a late software project makes it later, is why that last option is rarer than it looks.
- Don't guess under pressure. Asked in a meeting for a date on work nobody has estimated, commit to when you'll have a credible estimate, and to the part of the scope you already understand. Be decisive about the process and honest about the number.
Where this sits in the standard
Estimation, planning and honest commitments is competency DE-2 in the EMA Competency Framework, in the Delivery & Execution domain. The DE-2 unit of the Body of Knowledge sets out the models above with their sources, and what changes when a commitment spans several teams or is made to a board.
A typical EMA-I question here gives you a date that is slipping and asks for your next move. See what EMA-I covers, or compare the three levels.