The reason I don’t like #NoEstimates

Based on the first post of my blog one could think that I’m a strong advocate of estimating.  I don’t blame anyone who does, since the title was little provocative and exaggerated. But I don’t have any strong feelings about estimating — the reason I wrote that post is because I have negative feelings towards single-issue groups and hype.  Not just in the field of software engineering but in general, too.

#NoEstimates
#NoProductOwner
#NoTeam
#NoScrumMaster
#NoDailyStandups
#NoChairs
#NoBacklog
#NoScrum
#NoStoryPoints
#NoKanban
#NoTesting

What is common with the above listed(*) items is that they imply that thing X is categorically bad and you should get rid of it. I have one thing to say about that:

Bullshit. It all depends!

It depends on the problem domain, product, organization, team, stakeholders,  process, “agileness” of the people, phase of the project etc etc. I even claim that waterfall model would be perfectly suitable in certain situations and projects.

So, while I agree that planning and estimating are very common areas where there is waste and frustration in projects, I don’t like how that idea is represented and marketed. I say marketed, because the people that seem to be most loud about #NoEstimates seem to be people who get paid for talking, not walking.

(*) I’ve just heard of the first one, made up the rest of them. But if I had to guess, the next hype would be about product owners being evil and you shouldn’t have them. #NoBacklog would be my second guess.

2 thoughts on “The reason I don’t like #NoEstimates

  1. Thanks for saying what needed to be said “again.” Domain and context are critical to any conversation. The notion of not knowing what it will cost in the end or when we’ll be done “may” be applicable in some domains, where the budget is predefined and the period of performance is fixed. PayPal runs this way in some instances. Budgets are fixed on an annual basis and the features needed come from the field on an as needed basis, driven by the market’s need. The development is agile and responsive the emerging needed of the business development people.

    But other domains require estimates before starting and continuous updates to those as the project progresses.

Leave a Reply

Your email address will not be published. Required fields are marked *