Ravings on #NoEstimates

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.


#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.


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.


3 thoughts on “Ravings on #NoEstimates

  1. Estimates are not for developers, if the developers consider them selves “labor” rather than business managers.

    Estimates are for business managers, who manage their business using microeconomics of decision making for the future outcomes of their expenditures today. Any “Managerial Finance” text at the undergraduate level will explain why estimates of product cost and value are needed for the integrity of the financial health of the business and the project or products it produces.

    This is Business Management 101.

    No viable business can operate for long without a statistical forecast of cost, revenue generated from the value produced for the cost and the recurring cost and revenue once product goes into use. With confidence intervals and alternatives to choice – the opportunity cost that is the basis of Microeconomics.

    This is a core principle that cannot be ignored by any viable management process when spending other people money.

  2. Hi!

    Commenting on this, now, rather old post. But it caught my attention since you linked to it in a tweet 🙂

    A couple of thoughts:

    1. Estimates are “muda”. See this post: http://kodkreator.blogspot.se/2015/04/estimates-are-waste.html I.e expand that thinking to e.g eating. That might be “muda” (takes a lot of time and might feel wasteful – at least my kids seems to think so :)). Or breathing – all the effort we spend on that. Or (as in my post) taking care of your teeth.

    2. About “only a tool”. Expand that thinking to “math”. Math seems to be extremely hard to learn (look at all the children struggling at schools), and few manage to learn it really well. Should we find another tool than math or get rid of math?

    My point: it matters what we question. Estimates are as natural and ubiquitous as math. Although math is only “a tool for solving numerical problems” it’s also the only tool, because that’s how we define math. The same goes for estimates.

    But then again, it’s not how you define “estimates” in this post. And, when using “private” definitions, it becomes “problematic”…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.