What is it about “No Estimates” (or indeed, #NoEstimates) that gets people so angry? I had a great time last night at an open space discussion on this topic. Most of the room were using relative sizing, a small number used detailed estimates – but as a group we worked out what it would take to get away from estimating without throwing away the value we might get from them.
Most people in software development would be able to create a list of pros and cons for estimates. You might title the headings “benefits” and “harms” perhaps? What we are aiming for is a way of getting as many of the benefits and as few as the harms.
What we concluded was that there was likely to be a strong relationship between regularly delivering quality releases, building trust with the business or customer, and a drop in demand for estimates.
Frequent Quality Releases -> Trust -> NoEstimates
When I posted this conclusion on social media, it caused some strong reactions. Possibly because #NoEstimates just triggers some people, which is fine. It just hope to restore some balance in the discussion; because both sides have their merits and I would be nice if we all got to present them so you can make your own mind up (rather than simply being told by trolls).
Telling a business stakeholder “I can’t say when I’ll be done until I’m done” confirms the worst of IT stereotypes
You don’t get to a situation of #NoEstimates by using this kind of language. When you say “I can’t say when I’ll be done until I’m done” you won’t convince anyone that estimates may not be required (perhaps that is why it has been selected for use in this straw man argument).
On day one, in a low trust environment people want assurance. To give them this assurance, start delivering early and often. This will build trust.
#NoEstimates posits that we can tell the CFO, “staff my dev team for n months, & we’ll deliver something. You’ll love it, trust me.” Bzzzzt.
Again, although I suspect this is another straw man argument, I’ll cover it. If you said to a customer “fund me for two weeks and I’ll give you a release containing the first couple of features, then you can opt to continue funding or end the contract”, would that appeal more or less than “here is an estimate that says I can complete the project in six months, give me the money and I’ll send you a CD in six months”.
And then I realised the problem.
People must be interpreting the fact that “some teams have found that they don’t need to use estimates” as “YOU must stop using estimates”.
This is why they are getting quite angry and upset (and possibly why they have decided to tell me that I MUST be doing estimates, even though I’m not).
So here is my position on this.
I have found that as trust increases, many of the negative reasons for estimates disappear and many of the positive reasons for estimates are solved in other ways. Because there is so little value left in them, estimates just stop being needed.
You shouldn’t be aiming for #NoEstimates if you are operating in a low trust environment (and this includes an organisation working in a high trust environment taking on a new customer who doesn’t trust them, for example). Instead, you should be aiming to build trust.
If you successfully get to a high trust state – which takes a whole lot of hard work, regular releases, quality releases and transparency – then you may want to take another look at the no estimates hash-tag. In the meantime, don’t be too concerned with how people drive on tarmac if you are still driving on dusty roads.