In this probably too long post I will try to expose my thoughts on #NoEstimates as I see it. I will also try to give some pieces of answer to the most recurring questions and critics exposed by #NoEstimates opposition.

Twitter

#NoEstimates is by essence a twitter thing… and this is a plague, really. I’ve been reading many, and participating in some, #NoEstimates twitter conversations, and what really hit me is how much it is difficult to have a built conversation within 140 characters. It especially is with #NoEstimates because of an obvious vocabulary issue in the very definition of what an estimate is, and how much it differs from a forecast for example. I am convinced that many arguments about estimates would not have occurred if people would have first worked on a kind of “mutual understanding”.

So, for the record, and in order to make future conversations with me easier, I consider estimating as very different from forecasting in the sense that forecasting uses data to predict the future, usually with statistics and probabilities, while estimation is more based on experience and is more “vague”… but that’s only my definition and you may very well disagree. We just need to know what we are talking about before we start fighting.

Not doing estimates existed way before #NoEstimates

The first story I heard (read) of was the one of Dragos Dumitriu, as described by David J. Anderson in “Kanban : Successful Evolutionary Change for Your Technology Business”. This story dates back to 2004. There are of course many other “old” stories like this one, including from people in the anti-#NoEstimates side (I’m thinking of Trevor K. Nelson here).

What is important is that although the hashtag is rather new, the question is pretty old. This also means that Woody Zuill’s point of view (he initiated #NoEstimates as a hashtag for those who don’t know) has nothing to do with a dogma or anything of this kind. I find it’s a shame to read sometimes things like “zealotry” or “evangelical” when talking about #NoEstimates. People who wants to talk about not/less using estimates in software development can use this hashtag. Period. Woody Zuill has his own view, others have other views, no “absolute” here. #NoEstimates is neither a movement nor a religion.

Common sense

I am paraphrasing Peter Kretzman here, but I genuinely think that trying to get rid of estimates is pure common sense and I will try to explain this as much as possible.

muda

The first thing that comes to mind is that estimates do not produce concrete value. That makes them a waste in the sense of Lean. It seems logical, if you follow this paradigm, to try to get rid of them when possible.

only a tool

“[Estimates are] a tool, not an outcome” (Peter Kretzman, The case against #NoEstimates, part 3: NoEstimates arguments and their weaknesses). I agree with that. One of the main critics anti- have against #NoEstimates is “Don’t blame the tool because you don’t know how to use it”, and this argument is a bit flawed in my opinion : let’s abstract away “estimates” one moment and talk about a random tool instead. So let’s say we have a tool. This tool have proved useful many times but it appears that many people fail to use it correctly. This tool is intrinsically dangerous when not correctly used. Often it is so much misused that it can jeopardize the whole project, or the whole company. Facing with this situation in his company one can either

• Make the tool easier to use, which means change the tool, so that people can use it correctly
• Train people in the tool, so that they eventually manage to use it correctly. The “don’t blame the tool” critic live here.
• Find another tool that would do the same, or better, and would be easier to use
• See if we could completely get rid of the tool, maybe by changing the very problem the tool is designed to tackle

#NoEstimates is about the last two points, or a combination of both :

• some of the #NoEstimates advocates seek to find ways to remove estimates as much as possible and replace them when needed by forecasting based on actual data and statistics. A very common practice in the Lean/Kanban world.
• others – or the same actually – believe that by changing the business relationship we could completely remove the need of providing any kind of future prediction. Hence no estimates at all. Some relationships are more difficult to change than others though, and of course internal software development with fixed time and budget (“own money”) would be easier to do with no estimates than a fixed- scoped public-procurement based projects…

obvious in certain situations

There are domains where estimations are often not used at all, in nowadays’ software business. Unsorted : very urgent operations, fixed-budget fixed-time research and development, fixed-time options testing (UI design testing with prototypes for examples). You can figure some more situations I am sure.

We all agree !

Maybe the main thought I have about #NoEstimates, and it will be my conclusion, is that most of the #NoEstimates folk agree with most anti-#NoEstimates people. Unfortunately some barriers exist and it is our duty to try and break them so that the discussion go a step further. That is the goal of my Open letter to anti-#NoEstimates people.