The ultimate goal of building software is to deliver business value to the users of a system. This means a user story, being that a new feature or a bug, should move from the backlog to production as fast as possible.
When we have a continuous delivery pipeline in place we can deploy to production multiple times a day. This means we can, in the extreme, release each feature individually to production in an automated way.
To take advantage of the continuous delivery pipeline we cannot be held back by sprints. If you think about it, sprints are a mini iteration where features get queued to be deployed to production. This means waste is created because we have business value sitting in a queue for the duration of the sprint and we are not really leveraging our CD pipeline. How do we improve this? We can stop doing sprints and work in a flow like way (Kanban, as an example).
If we stop having sprints, we don't have to calculate what effort we can do in a sprint. This means we don't have to estimate anymore. The product owner makes sure the backlog is full and prioritized, the user stories are as small as they can be, and the team just grabs the top priority stories (bug or feature) and takes them from dev to test to prod.
With this flow approach you deliver value faster and remove the need for sprint plannings and groomings. The downside is that you cannot calculate velocity based on story points, but what's the value of that anyway?
Scrum isn't a silver bullet, it's just a great way to move away from waterfall and step into agile. But when the teams get mature enough, they can give the next step and venture in the Lean Software Development / Kanban world.