Estimates are a conversation, not a contract
The moment a team's estimate hardens into a deadline, you've traded honest information for a comforting fiction.
Most software estimates die the same death. Someone asks "how long will this take?", a team that has never built the thing before produces a number under pressure, and that number gets written down. From that moment on it stops being an estimate. It becomes a promise nobody actually made, defended by people who weren't in the room, against information that didn't exist yet.
The estimate was the most honest thing in the process — a snapshot of what the team believed on the day they made it. The contract is the dishonest part. It freezes a guess in time and then punishes everyone when reality, predictably, refuses to hold still.
What an estimate actually is
An estimate is a probability distribution wearing the costume of a single number. When an engineer says "about three weeks," what they mean — if you could read the shape of their confidence — is something like: probably two and a half, plausibly four, and if the third-party API we've never touched behaves the way the docs claim, maybe two. The single number is a lossy compression of all that. The compression is where the information dies.
The problem isn't that estimates are wrong. Estimates are always wrong; that's what the word means. The problem is treating one as if it carries no error bars, then building a roadmap, a marketing date, and a customer commitment on top of a number whose own author would have given even odds against it.
I've watched a "six week" project that everyone knew was a six-to-twelve-week project get committed to a customer as six weeks, because six was the number on the slide and nobody wanted to be the person who widened it. The range was known. The range was the truth. The slide kept the comfort and threw away the truth.
The conversation is the deliverable
Treat the estimate as the opening of a conversation and it starts earning its keep. The number was never the point — the point is everything the team has to surface to produce it.
When I ask an engineer to estimate, the answer I care about isn't the duration. It's what comes attached to it:
- →What are you assuming exists, works, or stays still?
- →Where is the fattest part of the uncertainty, and what would it take to thin it down?
- →What's the cheapest thing we could build first that tells us whether the rest is two weeks or two months?
Those answers are worth more than any number, because they're actionable today. A duration just sits there. An assumption can be checked. A risk can be retired. The estimate is the byproduct; the understanding is the deliverable.
A number tells you when to panic. The conversation behind it tells you what to do instead.
This is also why "padding the estimate" is a category error. Padding tries to fix a precision problem with more imprecision — it buries the real uncertainty under a fudge factor and pretends the result is safe. It isn't. It's the same fiction with a bigger number. Honesty about the range beats a confident lie about the buffer every time, because a range invites the right next question and a buffer ends the conversation.
Re-estimate out loud, on purpose
The most expensive mistake isn't the bad first estimate. It's refusing to revise it as you learn.
Every week of building converts unknowns into knowns. The team that started blind in week one knows the shape of the problem by week three. If the estimate never moves while the knowledge moves underneath it, you're not managing a project — you're protecting a number from the facts. The new information is the asset. Re-estimating is how you cash it in.
So make re-estimation routine and visible, not a confession extracted under duress. "Here's what we believed three weeks ago, here's what we know now, here's how the range moved and why" is not a failure report. It's the system working. A team that only revises estimates when caught will hide bad news until it detonates. A team that revises out loud, on a cadence, turns every surprise into a small adjustment instead of a late-stage explosion.
The teams I trust most are the ones whose estimates get sharper over time, not the ones whose estimates never change. An estimate that never moves isn't disciplined. It's stale.
When you genuinely need a date
Sometimes the world demands a date — a conference, a contract, a regulatory cliff. Fine. The honest move isn't to pretend the scope is fixed and the date will follow. It's to fix the date and let scope be the variable.
"We will ship something real by March 15" is a commitment you can actually keep, because you control what "something" means right up to the wire. "We will ship exactly this by March 15" is a bet against your own ignorance, and the house always wins. Hold the date sacred and the feature list negotiable, and you've converted an impossible promise into a manageable one. The conversation that follows — what makes the cut, what slips, what's the smallest version that's still worth shipping — is the same conversation a good estimate started. You're just having it on a deadline.
A date can be a constraint you design around. The damage starts when it stops being a constraint and becomes a verdict on whether the team did their jobs.
The fix here is not better estimation technique. No amount of story points or three-point math saves you if the output still hardens into a contract the moment it leaves the room. The fix is to keep the thing soft — to treat every number as a question you're still answering together, revisable the instant the facts change. Stop asking your team to predict the future and sign for it. Ask them what they know, what they don't, and what they'd have to learn to find out. Then keep asking, out loud, until the thing is shipped.
