Estimates, #NoEstimates, No Estimates
Photo by CEphoto, Uwe Aranas
I have said a thing or two about estimates in the past; and it generally leads to no good. What I do sometimes need to do is clarify my perspective, because people don’t get it. As always, definitions are important – so I’m to clarify what I think of when I talk about estimates, #NoEstimates, and no estimates.
I have covered this before in general terms in my definition of estimates. However, when I talk about estimates at work, in my own job, I’m talking about a subset of the definition of estimates. For me, there are a number of techniques you can use to estimate professionally that range from relative sizing techniques, to projections based on past numbers, to complex models of estimation.
When I am asked for an estimate, I always start by looking for the underlying need. Different needs require different kinds of estimation – and sometimes they can be satisfied without estimation. In software development, people often ask to be scratched when their real need is the removal of a thread-worm. Is it any wonder the people being asked to do this unsavoury scratching job are looking for better ways to solve the problem?
And that leads us to #NoEstimates. This isn’t a framework, or a technique, or a hipster replacement for COCOMO II. This is simply the exploration that searches for better ways of satisfying the underlying needs that surface in requests for estimates. It’s a discussion. Sometimes a heated one, but that’s okay. People may recollect occasions where they have been harmed by the mis-use of estimates, but others may also have been hurt by an unprofessional attitude towards their needs.
Refusing to give an estimate without providing a better way to answer the underlying need is the top cause of friction in the #NoEstimates debate.
And that leads to no estimates… or more precisely, it leads to eliminating estimates where they are the wrong solution to the problem at hand. In many cases this is fantastically easy.
You don’t simply stop estimating. You need to acknowledge problems and work in an open collaborative manner to solve them. In some cases, it may mean supplying a different kind of estimate to the one being requested. In others it is about re-focussing (for example where only the cost is being considered, and nobody has considered value). Ultimately, though, in many cases it will result in a reduction of the volume of estimates, because they are often the wrong solution to the need at hand.
The below diagram indicates that I don’t agree with blindly providing estimates simply because they are requested. It also illustrates that blindly denying the request is no better. The only path I’m interested in is one in which we find the need a solve it in the most appropriate way.
If you would like to read more, I have a flowchart that reflects the thought process of #NoEstimates in practice.