I have sat through a lot of conversations about estimates. How to make them more accurate, which technique to use, whether to use points or hours or t-shirt sizes. I used to think the problem was accuracy. I no longer do. I think most of the trouble with estimates comes from confusion about what they are for.
An estimate is a planning input
An estimate is a guess about effort, made with incomplete information, by the people who will do the work. That is not a weakness. It is the definition. Nobody knows how long a piece of software takes to build until it is built, and an estimate is the best available substitute for that knowledge at the moment a decision has to be made.
The decisions it supports are planning decisions. Is this worth starting? Which of these three things should go first? Can both fit before the conference? Do we understand this well enough to begin, or does the wide range tell us we do not? Those questions need a rough size, and a rough size is what an estimate is good at.
What an estimate is not good at is being a date. It was never a measurement of time. It is a measure of how much we do not yet know, expressed as a number because numbers are easy to put in a spreadsheet.
What goes wrong when it becomes a promise
The moment an estimate turns into a commitment, it changes what it is carrying. It stops carrying information and starts carrying consequences. And people respond to consequences the way people do.
The numbers go up, to leave room. Then they go up more, because the last ones were still too low. The conversation shifts from what we know to what we can defend. Engineers stop saying the honest thing, which is usually some version of I am not sure, and start saying the safe thing. Nobody is behaving badly here. They are responding to what the number has been made to mean.
I think the practical result is that estimates get less accurate as more weight is put on them, which is the opposite of what the weight was meant to achieve.
What I ask for instead
A single number hides the thing I most want to know, which is how confident the person giving it is. So I ask for a range, and for what would make it the low end or the high end. Two days if the API does exactly what the documentation says, two weeks if it does not, tells me more than seven days ever could. It tells me where the risk is, and often it tells me what to go find out before anyone starts.
I also ask what the estimate assumes. Most surprises in a project were assumptions nobody said out loud. Getting them said at the estimate is cheap. Discovering them in week three is not.
And I try to be clear about which question I am asking. Is this a sizing conversation, so we can plan? Or is this a commitment, because a customer or a contract needs a date? Those are different questions, and they deserve different answers. A commitment should be made deliberately, with room built in, by someone who is allowed to say no. It should not be an estimate that got promoted when nobody was looking.
Where this stops being true
Some work has a real deadline. A regulation takes effect on a date, a contract names one, an event will happen whether the software is ready or not. In those cases the team needs a commitment, and pretending otherwise helps nobody.
Even then, I think the honest path runs through the estimate rather than around it. Size the work, find the range, and then decide what to cut or add so the commitment is one the team believes. The failure I am describing is not committing to dates. It is treating every estimate as if it were one.
Photo source: https://photos.robertstowe.com/new-mexico