Agile Estimates versus #NoEstimates: Bridging the Gap
There are three truths we all know about estimates in software development: It is hard, we are really bad at it, and estimated projects always seem to end up running over time and over budget.
Now, there are two camps of agile practitioners who approach solving these problems in different ways:
- The Better Estimates camp—I’ll call it #BetterEstimates—says we should get better at estimates
- The #NoEstimates camp says estimates are a waste and we should stop doing them altogether
Agile teams can easily get puzzled by the heated debate happening between these two camps. However, by comparing how they solve these problems, we can identify many common practices between them and see they are not truly at odds—they actually complement each other.
Let’s bridge the gap together by exploring how the #BetterEstimates group and the #NoEstimates group approaches estimation at the project and iteration levels.
Estimates at the Project Level
The #BetterEstimates way
#BetterEstimates practitioners remind us that the need for estimates never goes away. For example, organizations use project-level estimates for portfolio selection purposes, helping choose between potential projects, maybe even before the teams are formed. Some projects might come with a hard deadline that must be met (getting something ready for a trade show, for instance), while others might come with other types of constraints. This high-level estimation is part of the data that businesses use in order to decide whether to even take on these projects.
Let’s say an organization has two potential projects. Project Alpha is a safe bet with few risks but also low ROI. Project Omega looks sexy and rewarding, but it comes with risks involved. If estimation for Project Omega concludes that it’s probably a twelve-month endeavor, it might be too risky. If, on the other hand, it’s estimated at nine months or less, then it might be a better bet than Project Alpha.
In an interview in Ryan Ripley’s podcast Agile for Humans, Steve McConnell, a thought leader in estimates, goes deep in detail regarding this type of estimation. He reminds us that 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
#NoEstimates uses the same agile maxim in another way. It asks, since we don’t know when we’ll be done, why are we still estimating and making promises (i.e., contracts) for when the software will be delivered?
For the most part, 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.
#NoEstimates exchanges the cost, uncertainty, and inaccuracy of project-level estimates with the agile practice of delivering value as early as possible. There are many techniques that use this approach, including walking skeleton, vertical slices, and creating a minimum viable product.
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. After a pilot is complete, teams can re-evaluate the feasibility of the product and decide whether to continue (and continuing simply means doing the next few iterations and re-evaluating again). This completely moves away from contract negotiation and creates a partnership with the client. I’s like asking the question, “Are we working on the most important thing for the client/user right now?” on a regular basis.
#NoEstimates minimizes risks by focusing on delivering value early and often and re-evaluating direction constantly. There are several reasons this approach is desirable:
- After a few iterations, there will be a much better way to forecast future iterations
- It uncovers the 80/20 rule (80 percent of the value will be delivered with 20 percent of the features)
- It’s open to changing directions of the project—teams can pivot at any time, even toward something not agreed on beforehand
- Teams don’t need to deliver something that is no longer necessary just to finish the contract
Bridging the gap
Estimation on the project level is sometimes necessary, especially when building software for more traditional clients or when selecting projects from a portfolio. But the real reason to estimate is to decrease the risk associated with starting a new project.
#NoEstimates proposes an alternative to decreasing risk without having to use estimation. It’s a valid approach because estimations are, at best, difficult to get it right. As Ron Jeffries, one of the founders of Extreme Programming, has written, “Even with clear requirements—and it seems that they never are—it is still almost impossible to know how long something will take, because we’ve never done it before. If we had done it before, we’d just give it to you.”
Estimates at the Iteration Level
The #BetterEstimates way
Agile operates with short feedback loops, and it’s a common practice to estimate our capacity in these short iterations. Some call it forecasting, and others call it capacity or iteration planning.
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).
On an episode of the agile podcast Meta-Cast, Bob Galen and Josh Anderson discuss how planning poker is about not just estimates, but also flushing out how the feature will be implemented.
Let’s look at an example. Say a team has five members, and when estimating a particular work item, four of them sized it as 5 story points, but John sized it as 13. However, John knew something that the others didn’t: that particular feature would have to also provide a workaround to a recently discovered system limitation. During the sprint, if someone else would have picked up this task instead of John, they would have missed this workaround, delivering either a buggy product or the wrong thing altogether. But because the team estimated this project, John was able to share this information with the team as they discussed this feature.
The most important activity of the estimation process is not the estimates themselves. It’s talking about the work that will be done for the next iteration.
In that sense, you can see planning poker, story points, and estimation as tools to get agile teams—especially nonmature teams—to discuss the work for the next iteration. As teams move along in their agility journey—such as when following the Shu Ha Ri model—they can start applying more advanced techniques, like the ones in the #NoEstimates movement described below.
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.
The problem is that #NoEstimates practitioners fail to mention this, which ends up fueling the debate when it’s truly not needed. The only difference in the two camps’ views is that pro-estimation advocates link these technical discussions with estimates, and #NoEstimates advocates do not.
#NoEstimates is an advanced skill that requires a clean codebase, high level of craftsmanship, and product owners and teams being aligned in working with small stories. After each iteration, #NoEstimates practitioners calculate the team’s velocity (or some other metric, like cycle time or counting of stories), which will help forecast future work on the upcoming sprints, encouraging a sustainable pace for the team.
So, in a sense, even #NoEstimates does estimating as well, even if it’s just counting stories—showing once again that these philosophies are actually not that different.
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.
Complementary Tools in the Agilist’s Toolbox
As the adage goes, if you only have a hammer, all problems look like a nail. This holds true for both #NoEstimates and #BetterEstimates. When looking at not only the benefits of #NoEstimates, but also when it’s not applicable, this idea becomes clear.
We can bridge the gap between these two camps. Despite what it sounds like at first, the #NoEstimates and #BetterEstimates approaches are not total opposites. They’re complementary tools in the agilist’s toolbox, and each has a time and place to be used.