NOTE: I'm hoping this serves as my reference point for answering questions about my thoughts on NoEstimates. I'll probably expand it over time as I get more data.

• 2018-07-05 - Initial Writing
• 2018-07-09.A - Clarifying the lack fo seeing arguments.
• 2018-07-09.B - Clarifying why arguments against the possibility are nil.

What are estimates?

I'm a software engineer. In my context an estimate is something assigned to a task I'd be ... tasked... with completing. The estimate is how long completing it is expected to take.

This is what I mean when I talk about #NoEstimates.

Estimation of individual tasks is not accurate. "But it's an estimate!!!" - Yeah... I can probably count the number of times I've been asked for an updated estimate on one finger.
Working in short sprints, things are normally broken down far enough (big design up front?) that if you sacrifice the practices, you might hit functionality. You'll lie to yourself, and your manager might lie as well that, "There will be time to clean up the code"...

Anyway - Why do we do estimates? Largely so the business knows how long some feature is going to take.
Why do they need to know the time a feature takes? So they can know how long an epic takes.
Why do they need to know how long an epic takes? So they can know how long it'll be to hit a milestone.
Why ... ok, we get the picture. We need to know how long things are going to take so that the business knows cost and when features are going to be available for the customer.

These are also estimates... typically. They aren't though. Not in the typical way. We're not estimating the Feature/Epic/Milestone like we estimate the Task.
I've seen them all as aggregate estimates.
The AggregateEstimate exists for a different purpose. It exists for business and to communicate when/what/cost of the actions of developing the software. Estimates exist to for those in the mine to know how long a specific task is going to take.

Different purposes, by different people, for different people. There's a lot of difference in the generation and use of Estimates and the information provided to the rest of the business.

Why do we call things created and used differently by the same name?

I need different terms if I want to compare and contrast these different things. As an engineer, my world has been primarily focused around estimates of tasks. That's really the place we actively "estimate".

That's the most frequent for me, so I'll continue to call that estimates.

Estimates: The time-scoping value assigned to the individual item a developer will work on.

Now - What about the other stuff? Each of them tends to stretch further and futhr into the future. We're looking at what's going to be happening in the future. ... Like a forecast.

Forecasts: The time-scoping value assigned to the deliverable the business cares/talks about.

With these two terms defined, I'm able to have a good discussion about them. I can compare and contrast these concepts. They are clearly different now. With different terms, I'm able to clearly communicate what I mean, without the confusion saying "estimate" for both of them are.

Time for Change

Can devs just stop providing estimates, with no other changes, and expect everything to go smooth? hehe - No. I've never seen that advocated.

The business still needs forecasts. A different mechanism needs to be in place to provide the business the value it need in the absence of developers assigning numbers.

There's a book about ways this can be done. Oddly named the #NoEstimates Book.

My Success

I've had a project that had an exceptionally unreasonable deadline. Complete the same work as another platform in less time than they've already spent, and aren't yet released.
I was given the project and expected to complete it in 7 months when other platforms had been in development for over 9 months without releasing.

I didn't estimate anything. We used a "Feature Board" style tracking system. (I really need to get that feature board post done...) This provided the PO excellent insight into the progress of the feature we were actively adding value to.
Whenever we got asked, "How long do you think it'll take?" we used the board and could use the historical trend to forecast when the feature would be complete.
We didn't give numbers to each task. We never even broke the feature into "tasks". We discovered the work we'd need to do by doing the work.
We started working. We applied XP practices, strictly. We worked on a feature until we got it done.
Then we did it with the next highest priority feature.
We got asked early on, "Well, you've got the N features, how long do you think each will take?" - Only answer I gave, "As long as they take". After a few features were complete, I used the average time multiplied for the remaining fetures to give forecasts. I never had to look at what a feature actually was. I had a trend, and I used that to forecast.

We did this for 7 months. Never estimating. Never digging into a feature to give a forecast based on the exact feature. We worked on the highest value.

We got it done and released in 7 months. I don't give NoEstimates the bulk of the credit for that. The bulk of the credit for that goes to the MicroObjects style of development and the strict adherance to the well known good technical practices of XP.
NoEstimates was crucial to the success though. We didn't waste time trying to figure out how long each thing might take. We didn't create waste by incorrectly designing a feature before doing any work on it.
We had no dates to be held to for a feature. We had no impulse to cut corners to meet the time-scope we gave, possibly months before.

Counter Arguments

I haven't actually seen arguments against No Estimates. I'd love to.
(BEG Update 2018-07-09.A) I had some internal context that I thought was implied by the next sentence (now paragraph), but apparently not enough. To clarify the lack of visibility of arguments against No Estimates - I've never seen an argument against no estimates that addresses why you still need estimates when you have different mechanisms for forecasting. This is what I've never seen. If it's an argument against NoEstimates, this is what I need to see. It's my undestanding of the whole premise. This is why defining terms is important, it allows meaningful conversation. I've defined exactly what I mean by estimate and forecast (always up for revision on those). So, back to the implied meaning that was originally in written...(END Update 2018-07-09.A)

As far as I can tell, it's all around a rejection of the terms actually being used.
This is why I start off defining things.

Estimates: The time-scoping value assigned to the individual item a developer will work on.

Forecasts: The time-scoping value assigned to the deliverable the business cares/talks about.

Business needs forecasts. There's a lot of other ways to generate these than breaking down everything into tasks a developer will work on (big design up front) and giving each individually a time-scope.

The business needs aren't being neglected. They're being recognized and we're trying to find better ways to provide better information.

Summary

No Estimates works. It's been applied on multiple projects I've been on. It's been applied to many more by others. It's been done FOR YEARS.

I'd like to see actual arguments against No Estimates being possible. Which, really, has to be nil as it's been successfully applied many times.
(BEG Update 2018-07-09.B) As there's been some confusion around the distinction of "not having seen arguments against NoEstimates under these definitions" and "arguments against no estimates being possible aren't going to hold water as the technique has been applied many times in many situations - so impossibility isn't a valid argument by the nature of a counter example". For simplicity, I'm striking that out as it's an after thought at the end of the ramble.

I'll udpate it to be: As NoEstimates has been applied many times across many products and projects, there has to be something useful there. I get the impression from opponents of NoEstimates that it can never work - Which is shown false by the existence of it having worked.(END Update 2018-07-09.B)

NOTE: Comments may be funky - No idea what's happening. If it's long, save it somewhere first. :)