Estimation is a communication problem

Every few years the industry rediscovers that software estimates are bad and proposes a new methodology. Story points. T-shirt sizes. Ideal days. No estimates. Reference class forecasting. Each one works for a while, mostly through the Hawthorne effect, and then stops.

The methodologies keep failing because they are solving the wrong problem.

what is actually happening#

When a manager asks "how long will this take," they are usually not asking for a prediction. They are asking one of these:

• Can I promise this to a customer for Q1?
• Should we do this or the other thing?
• Do I need to hire?
• Is this a two-week thing or a two-quarter thing, because those go in different plans?

Every one of those is answerable. None of them requires a precise duration. And a precise duration, given confidently, actively harms all four — because it gets recorded, propagated, and treated as a commitment by people three steps removed who never saw the assumptions.

The engineer knows the estimate is uncertain. The number arrives downstream stripped of that uncertainty. That is the failure, and it is a communication failure, not a forecasting one.

what to say instead#

Give a range with an explicit confidence.

"Two to six weeks. I'd take even money on three. The spread is because I don't know yet whether the legacy import path can be reused — if it can, it's two weeks; if I have to rewrite it, it's five or six."

That sentence contains everything the asker needs: a planning number, a worst case, and the specific unknown that determines which. It is also honest, which the single number was not.

Name the decisive uncertainty. Almost every estimate has one thing that dominates the variance. Say what it is. That converts "the engineer is being vague" into "there is a specific question we could go answer," which is actionable.

Offer to reduce the uncertainty.

"Give me two days to spike the import path and I'll come back with a much tighter number."

Two days to turn a 3× range into a 1.3× range is almost always worth it, and proposing it changes the conversation from negotiation to problem-solving.

Separate the estimate from the commitment. "It will probably take three weeks" and "I commit to delivering it in three weeks" are different statements, and conflating them is where trust gets destroyed. If someone wants a commitment, they are asking for buffer, and you should say what buffer you need.

why estimates are actually wrong#

Not because engineers are optimistic — though they are. The dominant causes, in my experience, in order:

1. Unknown unknowns in existing code. The thing you have to modify does something you did not expect. This is the biggest one by a wide margin and it scales with the age and size of the codebase.
2. Work that is not the work. Code review latency, CI flakes, environment problems, a dependency upgrade you did not plan, the meeting.
3. Scope discovered during implementation. "Also it has to work for the enterprise tier" arrives in week two.
4. Interruption. An estimate of three focused days is a lie if the person has two days of meetings and an on-call rotation.

Note that only the first is about the difficulty of the task. Most estimation error is organizational, which is why individual estimation skill improves results much less than people expect.

the thing that actually works#

Track your own history. Not for a methodology — for calibration.

Write down the estimate. Write down the actual. Do it for three months. You will discover you have a personal multiplier, it is remarkably stable, and it is probably between 1.5 and 3.

Then apply it. Silently. That single practice does more than any team-level process, and it requires no one else's participation.

the part managers should read#

If you punish an engineer for a missed estimate, you will get padded estimates forever, and you will have destroyed the information content of the number.

If you ask "what would make you more confident," you will get real answers and a team that tells you when something is going wrong early, which is the only thing that actually helps.

You cannot have both. Pick.