To estimate, or not to estimate: That is the question.

Or is it?

It’s not so much the act of estimation that’s the issue. Relative sizing can be a useful tool to help teams gain a shared understanding of a work item, and as a barometer for keeping batch size small. It’s what we do with those numbers afterwards that matters. Other than the value to the team, there are two common reasons why people undertake estimation: to try and eliminate uncertainty, and in an attempt to be predictable.

What’s the problem?
Things change. We don’t know what we don’t know.

In his book: How to Measure Anything – Finding the Value of “Intangibles” in Business, Douglas Hubbard tells us: “The commonplace notion that presumes measurements are exact quantities ignores the usefulness of simply reducing uncertainty, if eliminating uncertainty is not possible or economical.”

Most software projects undertaken are too big. The associated cost of the effort to break them down to a point where uncertainty has been eliminated, or for risk (defined by Hubbard as “uncertainty with an undesirable outcome”) to be completely mitigated, will never be economical or possible. There’s also the second order of ignorance: Lack of awareness, when we don’t know what we don’t know. That happens a lot at the beginning of a project, be aware of the Black Swan.

In addition, that work will still not account for the fact that things will change, that we want things to change so that we can ensure that we deliver the thing that is needed at the time we deliver it, not what was needed when we started. We like options, and pre-defined solutions limit us to only one option.

What is the alternative?
Woody Zuill writes on Twitter: “#NoEstimates isn’t “refusing to do estimates”. It’s being willing to question and discuss the issues of estimate-driven software development”.

I think that Woody and Doug could be saying similar things in different ways. Not estimating at all may be the Nirvana, but a lot of teams will not be in a position to achieve that. By keeping Hubbard in mind when we discuss estimate-driven software development, we realise that we may be able to ‘reduce’ rather than ‘eliminate’ uncertainty by working with a focus on the principles of Agile, using the uncertainty to lead the evolution of requirements.