#NoEstimates is easy

To discuss #NoEstimates (or #BeyondEstimates, I like it more, but let's stick with the "No" in this article) we first must define what an "estimate" is, before discussing it. Otherwise, we are not going to get anywhere in this discussion. And if we have a common definition of "estimate", #NoEstimates is actually quite easy.

The "broad" definition of estimate

First, I'd like to state that "no estimates" doesn't exist. What do I mean? If you merely look at the definition of the word, estimates are always present and always needed. What is this definition then? I take it from Merriam-Webster, I believe it's a reliable source, correct me if I'm wrong. Here it is: http://www.merriam-webster.com/dictionary/estimate. Read it and get back. 

Done? Great! A note, the definition talks about "cost". This is not the "money version" of cost, it's the "cost" of anything. As in the idiom: "Everything comes at a price" (again, not solely money).

Thus, it's used for making decisions. A decision is about choosing among future paths. And whatever we know about those paths, they're estimates! Simple.

That's the "broad" definition of an estimate. Always present, always needed when making decisions. The "world was once flat" argument is not relevant or equivalent, it's more like "do something has to be, or made, of a roughly round shape to roll?" Yes, it's the definition of "rolling". No one has ever thought anything else.

Thus, "no estimates" - in this definition - doesn't exist.

The "developer" version

But that's not how a developer would define an "estimate". And it's the "developer" version of "estimate" that #NoEstimates is trying to address. In my opinion, I must add.
What is this definition then? I'll give my version:
"The formal delivery of the estimated size of a task/item that is to be done".
I.e. the "process" that goes along with when someone asks a developer to "estimate". One, or usually a team, of developer(s) sit down and play some "planning poker" or whatever he/she/they do to come up with a figure or range.
This process is sometimes waste. This is what #NoEstimates is trying to address.
Note, I said "sometimes". It's not always waste. Sometimes it's actually very useful (depending how it's done, of course - improve!).

And that's why #NoEstimates is easy! Just start thinking! Question wasteful behaviors.
I.e. ask: "In this specific situation, is estimates (as the 'developer version' above) useful?"
An example: someone asks "Before you start working on this item/task, estimate it first!" Sometimes this is not needed. Just start working on it might be the most valuable thing to do. Whatever that reason might be. One example could be that everyone (even the one asking) has an "innate" feeling that the "size" of the item/task is not "2 hours or 1 week, it's something in between" and in this specific situation it's sufficient knowledge to know it's worth start working with it.You could call it an "implicit" estimate. Making it explicit would be better? Yes (see my "final thoughts" in this article). But, we are talking about the "developer" definition of an estimate here.
Hence, that estimate would probably not even be used for anything. Except maybe to use it as a commitment (a promise)?

There are a lot of examples of when estimates can be wasteful. This was just one example.

Some do this already. Some are already doing #NoEstimates. 

Thus, "no estimates" - in this definition - exists.

What #NoEstimates is not

#NoEstimates is not about "Everyone in the entire organization should probably stop estimating!". Because everyone in the organization has their own version of what "estimate" is. Depending on their role. For some, all their estimates is probably useful. And #NoEstimates is not trying to question those estimates.

A final thought

Let's play with a thought. A silly thought perhaps, but still a thought.
What if "the ones giving us money to write software" could estimate software work themselves? What if the "estimation process" then turned into a conversation with those providing us money instead?
"You may say I'm a dreamer, but I'm not the only one" :-)

TL;DR

As a developer I estimate all the time: "Should I write an if-statement or a switch-case? Should I create an abstract class or an interface? Where should I put this code? Should I write a test? Should I use this framework or that framework? Will this or that code be more readable? What will be most maintainable? What will have the highest performance? What will be easiest to write? What will take shortest time to write? etc etc etc"

Hence, "no estimates" doesn't exist. But it's not those types of estimates #NoEstimates is trying to address.