Engineering leadership and productivity tips straight to your inbox?

Agile Estimates versus #NoEstimates: Bridging the Gap

By John Lafleur 3 minutes read

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.

Estimation at the Project Level

The #BetterEstimates way

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.

The #NoEstimates way

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.

Bridging the gap

Both approaches come from a need to decrease the risks associated to the project.

Estimation at the Iteration Level

The #BetterEstimates way

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 way

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.

Bridging the gap

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.



Want engineering leadership and productivity tips?

Subscribe to our newsletter Weekly Bytes to get our curation of the top 5 articles of the week.
%d bloggers like this: