#NoEstimates In Practice
There is a great deal of talk on the #NoEstimates tag, but not a great deal of practical application of the concepts. There is also a great deal of backwards and forwards on the concept of “Aha! That is an estimate and therefore I win.” – yawn.
So here is a simple framework for thinking about #NoEstimates, which as we can remember is all about such concepts as:
- Questioning whether an estimate is needed
- Finding better ways of working that eliminate the need for estimation
- Finding better ways of satisfying whatever it is that causes people to ask for an estimate
The list above is not exhaustive, and it is okay that there is overlap (i.e. eliminating estimates is the right answer sometimes, other times it isn’t).
So here is how to use the framework for thinking about #NoEstimates.
When someone thinks an estimate is needed, you follow the flow chart through the various questions… does the need for an estimate reflect the real underlying need or is it a superficial request (for example, are they asking for planning, or because of a trade show in three months, or because of a regulatory deadline…).
If you don’t know whether it reflects the real need, you must find out what the real need is first.
Now you know what is really needed, you can ask whether the need can be solved in another way. If not, you will need to use an effective method for estimating. I prefer to use cycle-time-based projections, but Mike Cohn has written an excellent book called Agile Estimation and Planning that has some great techniques.
If you can think of potentially better ways of satisficing (not a spelling error) the underlying need, you should try it out in collaboration with your customer. You may need to try it a few times to collect enough data points to really call it an experiment and you may need to refine it, or run it alongside your old method for comparison.
So how does it work in practice? Here are some real examples of #NoEstimtes in real life from some of the organisations I worked for.
Where a product was being developed with a big return on investment (i.e. it didn’t matter whether we spent x or 10x on the development) we started the development with a fixed burn rate, used Neil Killick’s slicing heuristic and at the management level made some projections using cycle-times. There was no need for estimates from the technical team, and the projections helped with planning – particularly with ordering the list of features and deciding whether a cut down version of the product launched sooner would be better than a more complete one launched later.
Where an absolute deadline was on the horizon, we hit the ground running and used visual progress to manage the work. The project was a game of Russian roulette with two barrels, because it could only be delivered on time, or be worthless. The only angle of attach was to divide it between the elements that were absolutely necessary, and the elements that had crept along for the ride like mud on boots.
In many cases, after asking why people needed an estimate I have found that they were more interested in when something could be started, how often we deploy software, or whether something was worth doing at all. There are also many instances of estimates being misunderstood because of a lack of discipline – just because something might take “three to five days” doesn’t mean you’ll have it next week… it may not have even started by then. These misunderstandings can easily be solved by removing assumptions about what “a number” really means.
There have also been times where someone has casually asked, “does this change make things harder” and I have casually answered “I think it adds two to three weeks extra effort”. In these cases, the relaxed nature of the conversation has come from my certainty of how these numbers would be used.
But some of this is estimation!? Yes, of course. I use #NoEstimates to question whether estimates are needed, and whether they are what is needed in specific situations. I am happy to bow to the economics of a situation and I also like to choose the ground that I believe is worth defending – not all of it is worth bleeding for.