Ron Quartel recently put relative estimation to the test and shared the results in his recent post, Putting Relative Estimation to the Test. His main finding was that absolute estimation becomes more accurate than relative estimation… as you add more people providing absolute estimates (that’s the key bit). The implication here seems to be that if you have a large team (i.e. approaching Dunbar’s number), you may be better off doing absolute estimation as long as you involve the entire team.
Since estimation (especially estimating at scale) tends to incite so much conversation, I thought I’d take a look through Agile Alliance content and see what other perspectives we’ve seen over the years.
Alternative to Hours in the Ballpark
Teams wanted to get away from the inevitable request for a “ballpark quote” expressed in hours that they would be held to, even though they had little information with which to back up what amounted to guesses. You may find it a bit ironic that these ballpark quotes often ended up being absolute in nature.
The common way teams found to get away from the ballpark was some sort of relative estimation using story points or some other unit of measure that is decidedly not time-based. This approach is roughly based on the ideas that Mike Cohn shared in his often-referenced book Agile Estimating and Planning (affiliate link). The technique most often used for this activity became known as planning poker.
As teams got more comfortable with estimating in this fashion, they found that their estimates, or perhaps the disparity between plan and reality, did not always get better. Some thought it might be due to the techniques they used. Linda Cook shared her views on the pitfalls of planning poker, pointing out that planning poker was intended for sizing user stories, not generating estimates. Others, like Hans Samios, thought their estimates were terrible and shared the story of what they did as a result.
Still, others thought that maybe teams needed a better understanding of the techniques that were in common use in the Agile community. That resulted in sessions at the Agile20XX series of conferences. Some examples include:
- The Agile Planning Mindset (Subscriber) – Peter Green Agile2013
This session shows how to use visual grouping, affinity estimation, planning poker, and release forecasting using velocity to teach relative estimation.
- Experimenting with Bulk Estimation (Subscriber) – Dan Grenning Agile2014
Bulk estimation can make backlog refinement shorter, more useful, and more predictive. This workshop explains the approach and explores when it makes sense.
- Missing the Point with Backlog Item Estimation (Subscriber) – Chris Li Agile2017
This session revisits what a Product Backlog Item represents, what an estimate represents and a common pattern in organizations that don’t understand these concepts.
#NoEstimates and Other Alternatives?
Around 2008 – 2009, people started to question whether relative estimation via techniques like planning poker was the answer. They started exploring different approaches, such as Pawel Brodzinski who explored a variety of different approaches to estimating and suggested that what people really were doing is forecasting.
Troy Magennis extended the exploration of forecasting at a couple of conference sessions. At Agile2014, he, somewhat ironically, invoked the approach of “Moneyball” in baseball (Baseball is played in a ballpark. Think about it for a minute, you’ll get it) to describe how to use metrics to forecast software development work (Member). At Agile2016, he extended the discussion and talked about how to forecast using data (Subscriber), which allows you to answer questions such as how big, how long will it take, and how likely are we to finish it without backlog item estimates.
Then came the provocative, and potentially misunderstood conversation #NoEstimates. A few used and interpreted the hashtag to mean teams shouldn’t do estimates whatsoever. The real intention was to examine estimates, whether they always made sense, and what they were used for. A variety of sessions have occurred since 2014 exploring this topic. Here’s a sampling:
- #NoEstimates – Applied, In Depth, and By Experience (Subscriber) – Matthew Heusser (Panel Discussion including Troy Tuttle, Troy Magennis, Markus Gaertner, and David Hoppe) Agile2014
This session discusses how experiments with estimation turned out, how you can uncover #NoEstimates in your organization, and what to do about it.
- NoEstimates (Member) Woody Zuill AATC2016
Estimates in software are ubiquitous. Some love estimates, and some hate estimates. Woody asks questions. This is an invitation to find the right questions.
- To Estimate or #NoEstimates, That is the Question (Subscriber) – Todd Little Agile Europe 2016
In this talk Todd analyzes real data from over 50 projects to explore when estimates add value and when they do not and provides pragmatic estimation advice.
- The State of No Estimates (Member) Woody Zuill Agile2016
This session explores estimates, why they are pervasive in the programming world, how they might be harmful, and proposes better ways to make decisions.
- The #NoEstimates Movement (Subscriber) – Ryan Ripley Agile2017
This session explores how teams can use #NoEstimates thinking to meet stakeholders’ needs, maintain alignment, and use metrics to know when they deliver value.
The Gist
Here’s what I took away from looking through all of these resources. Think about why you need estimates. What decisions are they helping you make, then pick the approach that provides the right balance of information, accuracy, and effort so that you can make that decision. The approach you select may differ depending on your situation. Choose wisely.
Photo by Aldric RIVAT on Unsplash
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
