Estimation Is Not Guessing. It Is Structured Discovery.

I often ask Product Owners and developers to estimate work in hours before they feel ready. The first reaction is usually resistance. The work is too complex. There are too many unknowns. It cannot be broken down yet.

That reaction is the point

When someone says a piece of work cannot be estimated, they are usually not telling you that estimation is impossible. They are telling you that the work has not been understood well enough to discuss responsibly.

A wide estimate is not a bad estimate. It is a flag.

What the estimate reveals

When one person sees three hours and another sees three days, the useful information is not the average. It is the difference between their assumptions. One imagined an existing component. The other imagined building it from scratch. One assumed clean data. The other knew the data was a swamp.

How to use estimates well

• Treat divergence as the signal, not the noise.
• Ask what each estimator was assuming.
• Write down the assumption — that is now a requirement or a risk.
• Re-estimate only after the assumption is resolved.

Done this way, estimation becomes the part of the process where requirements actually finish getting written. It is not a promise. It is structured discovery with numbers attached.