Consider the Value of #NoEstimates in Your Organization

It’s not clear that estimation is very helpful to many teams. Too often, the product owner wants to change the stories to provide more value. Or the team realizes that the story it thought was small is not small. Or the team gets into the code and realizes the code is a mess.

The consequence is that all the estimation the team did is useless. The team will work in a different order, or the estimates are off.

What if you worked without estimating, and instead worked by value? That’s the promise of the #NoEstimates philosophy.

Sometimes there’s value in estimates. You can provide a ballpark, an order of magnitude about how long this project or feature set will take. However, if you are working in an agile way and you have a team that is able to maintain a steady throughput of value, you might not need to estimate at all.

Imagine this scenario: the product owner creates stories either alone or with the team that take one day or less for the team to complete. The team swarms or mobs on the stories, so everyone knows what they need to do and when. The team has no or very little WIP because it releases stories as they are finished.

In that case, what is the value of estimation? You might need to count the stories and see how many remain so you can see how many days are left in that feature set.

In a serial life cycle, the team only releases value at the end of the project. With any luck, your team releases value at least every two weeks. The value of estimation changes when the team releases value that often.

You might no longer need estimates to provide the same service to your management.