My answer would be "Yes, but…"
I've always said:
"Estimation is valuable, estimates are waste"
So if you can get the value that you would get from estimation in another way that provides a valuable output as well, then estimation is waste.
However a recent chat with Colin got me thinking about how I present that thought, as it has a subtle nuance that makes all the difference.
Let me break it down, starting at the back end. "Estimates are waste"
In IT we tend to work on Complex Adaptive requirements, so trying to pin down how big work really is before we start it is next to impossible. The estimate itself doesn't actually deliver any value to us, it's the work item itself that delivers the value, so, the time we spend estimating is time we could have been spending working on the work item, and allowing the emergence to occur. In other words we are wasting effort producing something that doesn't actually deliver any value and reducing the time we have available to do the work itself.
But, "Estimation is valuable"...
I said it (on the internet no less) so it must be true. When a team spends time estimating, we are taking parcels of knowledge which is locked away in the heads of individuals (usually more than one) and sharing it amongst the entire team. We are turning tacit knowledge into explicit and shared knowledge.That is a very powerful and valuable thing to do, as it means we are working with our eyes open rather than working blind to knowledge we already have partitioned away within the brains of individuals.
So if we are in a Kanban team and stop estimating, how do we still get this hidden value of estimation? Well we can use something like BDD (Behaviour Driven Development) to have the same discussions, and bring out the tacit knowledge.
So that's all sorted then, so why the Blog post Dan?
If a team starts out as a Scrum team, then it will do estimation as part of grooming and planning. We learn about drawing out tacit knowledge and making it shared and explicit. We intrinsically start to understand the value we get from it. We can then evolve into getting the same knowledge and value from other activities such as BDD, and therefore stop estimating all together, recouping the waste and replacing it with something of value (Gerkin tests).
If we don't go through that learning, but jump straight to not estimating, we haven't learned about the value we are missing. We may well not know we are missing it (although we are likely to be very frustrated by work seeming to have very high levels of emergent work).
There is a reason we advocate evolutionary change rather than revolutionary change in Kanban, so we should Limit the Change in Progress to an acceptable level for the team in question, and we should only abandon estimation at the point when the team knows the value it gets from it, and has an effective way of replacing that method of gathering that value.
Estimate on, until you know what you're missing, then find a way of getting that same value from something else before you stop estimating.