TL;DR: Agile teams can easily get puzzled by the heated debate happening between the #BetterEstimates and #NoEstimates camp. However, we can identify many common practices between the 2 groups and see they actually complement each other. Let’s bridge the gap.
The need for estimates never goes away. Some projects might come with a hard deadline that must be met (getting something ready for a trade show, for instance). The Agile Manifesto advocates for customer collaboration over contract negotiation, so if customers are asking for an estimate in order to minimize their risk, why should we not give it to them? The solution here is to get better at estimates.
Estimation is done in order to understand and minimize the risk associated with the development process. The #NoEstimates movement approaches minimization of risk in a different way. Instead of asking how long a product will take to be implemented or how much it will cost, it asks what kind of software is possible within a certain period of time or amount of money.
For the cost it takes to estimate a project, teams can fund a pilot that tests the idea of the product and generate insights into what delivery schedule is possible.
Both approaches come from a need to decrease the risks associated to the project.
Iteration estimation takes place when the team is already working on a project and uses historical data to forecast future work. Agile software teams focus their estimates for the next few iterations only and decide how much work they are going to commit to during each iteration, providing a mechanism for delivering software at a sustainable pace.
Planning poker is a popular technique for estimating work for the next iteration. This practice also elicits important technical discussions about the work that’s about to be done, including aspects of architecture, design, implementation, testing, security, and performance. At the end, any team member should be able to implement this particular work item (solo, if necessary).
The #NoEstimates approach to capacity planning is based on the observation that large stories are harder to understand and estimate than small stories; therefore, teams should always split all large stories into a number of small stories. This way, teams eliminate the need to use story points altogether. In order for teams to forecast capacity for future sprints, they simply count the number of stories they finish in each sprint. The focus here is on refining and slicing user stories.
Those in the #BetterEstimates camp criticize the #NoEstimates approach because, since they don’t estimate, they don’t play planning poker, and therefore they miss the benefits that brings, including the technical discussions it facilitates. #NoEstimates practitioners agree that these discussions are important, but they argue they can take place outside the realm of estimation.
On the iteration level, #BetterEstimates and #NoEstimates have more similarities than differences. Both advocate using the team’s past data to forecast future capacity. Nonmature agile teams can use planning poker and estimates as a tool to grow in agility and move to the #NoEstimates approach of having small stories in place. The important part is to continue discussing work, whether using planning poker or another approach.