To estimate or not to estimate - #noestimates by slicing

At the risk of stating something that is already obvious - "#noestimates" does not mean "We don't have any idea what we're building or how much it costs". It means we have simplified the process to a point where risk and reward are in a sound correlation.
There are many ways to reach a state where estimates are no longer relevant. Here, we will discuss Backlog Slicing and its effect on estimation.

One way to remove the need for estimation is to slice deliverables into packages no bigger than 1 single day: At worst, you have lost 1 day and learned that in 1 day.

When you can do this slicing for any given backlog item within a couple minutes, it becomes completely irrelevant whether the slice is actually 1 minute or 8 hours, since the Law of Big Numbers starts to kick in at some point and it becomes fair to say that a deliverable is about 4 hours.

So, even with #noestimates we actually do have an estimate, but we don't bother going through all of the items individually, attaching a "4 hour, could be more or less" label to each and every one of them.

With this information, we can also predict cost and duration:
How many slices do we get out of a "requirement"? 1, 20, 1000? How many of them are really needed?

 Then we optimize: Can we deliver the bulk of the value by doing only a couple of them?

 Lastly, we can quickly observe and act: Do we consistently deliver an about even amount of slices per week? Does the number increase or decrease? Are there any significant outliers that clog the pipeline?
By observing the answer to this question, we imply data without actually measuring it:
As long as the consistent flow of delivery is there and there are no outliers, there is no problem.
On the other hand, when we seem clogged or bogged down, we realize this immediately, because we're not delivering any more.

 This becomes visible and can be fixed within a couple of days, so we can go without a company-wide measuring system that may tell us the obvious by the time the team is already working on a solution - or even worse, waste precious development time by holding the team accountable to solve a problem that we can't influence.


 Summary
#noEstimates is not equal to abolishing good business practice due to negligence or inability.
 Much rather, #noEstimates is a sensible step of evolution for developers who have mastered their technical domain, whose Product Owner is crystal clear on business value and priorities - and for  people with a very rigorous and keen Continuous Improvement mindset.

 A team avoiding Estimates without these three aspects in place may act haphazard.

So, #noEstimates is effectively "Implicit Estimates without explicit estimation overhead".