NoEstimates might be the way to profit from estimation without the burden of dealing with Story Points.
Prediction is very difficult, especially about the future.
âNiels Bohr (and others)
For years now, agile teams have been using planning poker and other methods to estimate the effort needed to implement a product backlog item (PBI). The practice not only helps to prepare future iterations; it's also a helpful indicator for the prioritisation of PBIs. Of two items with similar expected benefit, you'll usually want to implement the one first that will cost less to build.
Perhaps most importantly, estimating effort has proven to strongly support conversations about the details of a PBI. Understanding the requirement precedes building an opinion on its required effort.
There's a catch though. In the context of agile software development, we're generally speaking of building novel systems in the complex realm. Had we built it before, we would just re-use it; we wouldn't estimate implementation effort â we would just put a price tag on a feature. But we do estimate because we do not know exactly how much work it will take. It is too easy to confuse both, and to mistake an estimate for a promise.
NoEstimates therefore suggests doing away with estimates. At first I wasn't convinced, because I find the resulting discussions useful. As it turns out though, you can get rid of estimates while continuing the practice of estimation . As Lunar Logic's recently published estimation poker deck ( available in regular and politically correct editions) beautifully illustrates: You can have a meaningful conversation without needing to differentiate between 5 or 8 Story Points, and it can probably even help you finding the right granularity for your PBIs.
It may be just enough to negotiate until everyone have understood the exact need, and agree that it can reasonably be built. If you have tried it: What's your experience?