Sick and tired of Agile estimation – #NoEstimates

Agile Estimation

During this last week, I finally had the opportunity to read a book that was on my reading list for long time: Black Swan by Nassim Nicholas Taleb. The book is about uncertainty and unexpected events.


NNT (as the author calls himself) explains that we live in an extremely complex world where we cannot predict all the events which will happen, and therefore it is silly to try to plan or predict future outcomes.

Throughout the book, he mentions several events that humankind did not dream of that caused terrific outcomes.

Even living in this complex world, we always try to plan everything. We always try to predict the future. But, like NNT shows us, Plans fail because of what is called “tunnelling”: the neglect of sources of uncertainty outside of the plan itself.

We humans believe that we are good at forecasting if we do the same task over and over again; we think the more routine the task, the better we learn to forecast… We just forget there is always something non-routine in our complex world that will destroy our forecasts.

Like NNT explains: most delays and cost overruns arise from unexpected elements that did not enter into the plan—that is, they lay outside the model at hand—such as strikes, electricity shortages, accidents, bad weather, or rumours of Martian invasions.

We cannot project the behaviour of a system if we do not know all possible conditions of that system, therefore we cannot truly plan; all estimations will be, most likely, completely wrong. Let’s make the bridge now into software development.

Everything that I described before can be applied directly to software development, so why the heck do most of the companies (in my experience) still ask for detailed plans and estimations? It’s ridiculous to even start when we already know that we will be wrong!

Why do we still have Senior Management asking for milestone plans with detailed lists of features for months? Why do we have people bothering themselves with Gant charts full of detailed information that will be obsolete as soon they finish printing out the Gant chart?

Why do we have management looking into sprint reports, asking why the Delivered stories are not as high in number as the Committed stories? Why do we even have management forcing people to learn “how to get better at estimation”?

Why do we have management bothering Scrum Masters with questions like: “Why does the sprint burn down have several peaks? I would like to have a normal line!” Why do we have teams spending hours in useless estimation meetings where they discuss if the story is a 3, 5, or 8? Even worse, why do we have teams spending entire days doing estimations for complete product backlogs?

All the previous examples can be considered evidence of fantastic waste! We spend days and days trying to achieve what we cannot, so what can we do to avoid all this waste? The solution is simple: DO NOT ESTIMATE.

Woody Zuill is a guy that is writing a lot about #NoEstimates; there are many more people doing so, but Vasco and Woody are the ones that I am following quite closely. I am starting to talk about the topic more often myself; for example, you can see my previous blog post about this right here.

The idea behind this approach is simple: We understand that we cannot do any kind of estimations, therefore we do not lose time trying. But how can we predict where, exactly, we are going to land? We cannot, but we can provide a time interval wherein the product will be ready. At the same time, we guarantee that we can deliver the highest value to the customer in small intervals of time.

In conclusion, I want to remind you all that there is no way that we can predict the future. There is no way we can do exact estimations, so let’s stop this wasteful practice and start doing things much more simply.

I would love to get a star rating for this post:

Sick and tired of Agile estimation – #NoEstimates
4.31 (86.15%) 13 votes

Leave a Comment

  1. Pingback: Reading Recommendations # 26 | Adventures in QA

  2. Pingback: Five Blogs – 20 July 2015 | 5blogs

  3. Reply

    Nice discussion here :)

    First and foremost: estimates are not deadlines. They are our best guess of how long it will take to do something, and that’s fine. It can be an interval, no problem. But they cannot be taken as a commitment, which is what happens a lot of the times.

    Estimating is ok and, sometimes, necessary. I’ve seen teams that can’t work properly without it and I’ve seen the opposite. I tend to favour some estimating, but the unit of masure can be quite different from time: it can be size.

    A recent project I was in, the team was doing a major refactoring of the codebase, along with an all-new UI. They kept on pushing the estimated release date (month) and I realized immediately they hadn’t tought properly (eg: estimated) how long the work would actually take. I got them to do rough estimates and finally we all had an idea of when it would happen. It helped us a lot, specially the team, and making decisions on what should be taken away was easier.

    In the end, it’s common sense. I see no value in estimating 1 hour tasks but I do see value in having an idea of effort. Focus on having an idea.


  4. Reply

    I agree here with Luis.
    I working as SM with my team and we did stop hard estimation some time ago, and it’s working for us.
    From my experience everything depends on team and project, if it’s “easy” and you have knowledge you can play with estimation. In our cases most of user stories looks like a trap and you don’t know what’s in even if you spend some time on research in previous sprint’s.
    Don’t go with the book. Try what is working for you and use it ;)

  5. Hi Luis,

    I agree that a clear definition of the difference between forecasting and estimating is needed for this discussion to be as helpful as it can be.

    Estimates have been an area of abuse and political shenanigans for a long time, and yet a necessary thing. Estimation is necessary if it’s done in a short-term tactical way. That is what I call a “rough estimate” and I believe it is the same thing you mean when you say “forecast”. But I would like to hear your view on that:-)

    There is tremendous value in communicating to senior managers the concept that you describe from Black Swan. For them it means they cannot hide behind estimates (and here I mean the long term overly-detailed kind) extorted from the lower ranks: they need to state their assumptions, make a strategy, and find a way to carry it out with the ability to change it along the way.

    That’s a tall order, but the really good managers / leaders recognize it as the responsibility *they* need to carry.

    – Nancy V. @vanschoo

  6. Reply

    What’s the difference between rough estimates and forecasting?

    • Reply

      Completely different Daniel :)

      Forecasting is based on past data, estimating is pure gut feeling :)

      • This is the first time I have ever seen estimating defined that way. I have always based my estimates on past data. But there are two issues with this, no matter what name you give to it

        1. There will be some work too new for any past data to apply

        2. The past data you have is not 100% applicable, and you have to use judgment to decide how to handle the gaps

        You’ve described forecasting as not taking up the time that estimating does. Do you mean that you’re strictly applying the “yesterday’s weather” idea?

    • Brian Johnson
    • August 12, 2014

    I recently wrote a short blog post on the same topic and provided what I think are some reasonable alternatives:
    If you are providing a time interval, you are still estimating and the estimates are still not likely to be accurate on average unless the time interval is very large.

    • Reply


      You are not estimating :) You are forecasting :) Its different ;)


  7. Reply

    Hi. I totally agree with Antti Sulanto.
    I personally estimate some things even if I know, that they can be wrong.
    And it’s a part of knowledge to think about what yould happen and use this information for estimation. Of course this is not a guarantee – but it still helps.

    In a week I will go on holiday with my wife and my three kids. We plan to arrive at a specific time to check in at the hotel. I know the way, the miles and so on – I know it’s holiday time and I know that I cannot now if there will be heavy traffic or a traffic jam. But I need to decide when to leave home, if we would like to make 2 or 3 stops inbetween and so on.

    For me it’s (currently ;)) not the right way to condemn estimations just because they will be wrong. The problem is not the unpredictability of estimatins (as Antti Sulanto said they are inaccurate by definition) but the expectant attitude of some managers and instead of doing no estimates it’s better to learn with them what estimation means.

    Other example: if I go to a service station because my car broke I want to have an estimation when it will be repaired. In worst case it will take longer – but usually I am happy to get the car as expected. I wold not like to go there and hear the mechanic say that he could not tell me when it will be repaired…

    For me it’s a better way to use Story Points (for example) and not to mach them with hours or days in detailed planning but to give them as a rough estimation. Luis – I agree with you when you talk about “detailed plansand estimations – that’s too much work for unpredictability – but rough estimates are very helpful and needed in most of the customer / service provider relationships.

    • Reply

      Thanks Daniel :)

      I cannot understand how wrong estimations can be useful in any form :) I see it as a waste :)

      Why the heck loosing time with something that we know its already wrong! Just use the historical information that gives you much more information. Do forecast instead of estimations :)


      • Reply

        if I say something will be between 5 and 7 days and it ends up with something between this period the estimation it’s not a wrong estimation. an estimation gives you a feeling when it will be done…

        it’s not needed for developing but to work with shareholders and I totally agree – working with historical information and do a forecast is a good way. but for me it’s just another way of doing estimates – it’s an estimate when things will be done…

        and even a Product Owner sometimes needs to get a feeling about efforts cause sometimes this effort is relevant to decide if a feature is done “big” or “small”….

      • Reply

        this is what i meant with my last paragraph… first of all you need historical information to do so. what do you do if you don’t have them?

        of course you should measure and use this measurement for a forecast – but this is just anouther way for estimation and described with different words.

        if you work with experienced people and teams they use their knowledge (historical information) to estimate…

        what’s the difference between forecast and estimation?

        in my opinion it’s still more important to discuss expectations… what about my examples with the holiday trip and the mechanic?

    • Nick
    • August 11, 2014

    The link with Black Swan is tenuous at best. The book refers to the incorrect use of models (normal distribution) to predict outcomes in environments where extreme events are far more common than expected (fat tail). Hence people take far more risk than they think they are. There are established statistical models for estimates that can be used if accurate estimates are required.

    • Reply

      Taking what you said:

      “The book refers to the incorrect use of models (normal distribution) to predict outcomes in environments where extreme events are far more common than expected (fat tail)”

      Perfect connection to software development, in my opinion.

      “There are established statistical models for estimates that can be used if accurate estimates are required”, yes right ;) specially in software development ;)


  8. Reply


    I’d like to address one of the things you’re writing in your post:

    “[…] we cannot predict all the events which will happen, and therefore it is silly to try to plan or predict future outcomes.”

    But, by definition, estimates are inaccurate. We cannot predict all the events which will happen, yet we *can* make estimates. Yes, they will be inaccurate, but they still can be useful.

    I hate to use a trite example but take weather forecasts for example. Are you still sure we cannot predict the future, with inaccuracy? Do weather forecasts have zero value, because — gasp — they might be wrong?

    • Reply

      Hi Antti,

      Thank you so much for taking the time to comment on my blog :). To be honest with you I do not think that estimate for the sake of estimate is useful :) The discussion of what needs to be accomplished by the team is good but not the estimate for the sake of estimation. In most of the companies you end up having discussions with management about why they did not deliver what they committed. I think this is just waste.

      And yes I like what you have said about forecast because that is exactly what I do: “Forecasting”. Forecasting is different than estimating. Forecast is predict where you are going to land based on past information, purely estimation does not do that. You just look to the piece of work and think how long it will take.

      With my teams I do not lose anymore time with estimation, I just look to the amount of stories, the team makes sure the stories are broken in small pieces (1day) and that´s it.

      Hope this helps.

More from our blog

See all posts

Can a non-Tech person be a scrum master?

Continue reading

Demo – Anti Patterns

More a presentation than a review No review of timeline or budget…
Continue reading

Planning – Anti Patterns

No looking at previous velocitiy Blind acceptance of P0s proposal Backlog not…
Continue reading