I have sat through a lot of conversations about estimates. How to make them more accurate, which technique 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 is 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 software takes until it is built, and an estimate is the best substitute when a decision has to be made.
It supports planning decisions. Is this worth starting? Which of these three goes first? Do we understand this well enough to begin, or does the wide range say we do not? Those need a rough size, which is what an estimate is good at. What it is not good at is being a date. It measures how much we do not yet know.
What goes wrong when it becomes a promise
The moment an estimate turns into a commitment, it stops carrying information and starts carrying consequences. The numbers go up, to leave room. Engineers stop saying the honest thing, usually some version of I am not sure, and say the safe thing. Nobody is behaving badly. They are responding to what the number now means.
I think the practical result is that estimates get less accurate as more weight is put on them, the opposite of what the weight was for.
What I ask for instead
A single number hides what I most want to know, how confident the person giving it is. So I ask for a range, and what would put it at either end. Two days if the API does 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 what to find out first.
I also ask what the estimate assumes. Most surprises in a project were assumptions nobody said out loud. Saying them at the estimate is cheap. Discovering them in week three is not.
And I say which question I am asking. Is this sizing, so we can plan? Or a commitment, because a customer or a contract needs a date? 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 happens whether the software is ready or not. Then the team needs a commitment.
Even then, I think the honest path runs through the estimate rather than around it. Size the work, find the range, then decide what to cut or add so the commitment is one the team believes. The failure is not committing to dates. It is treating every estimate as one.
Photo source: https://photos.robertstowe.com/new-mexico
Top comments (0)