Perspectives on Estimating

Added to Process

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 backup 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 off 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:

This session shows how to use visual grouping, affinity estimation, planning poker, and release forecasting using velocity to teach relative estimation.

Bulk estimation can make backlog refinement shorter, more useful and more predictive. This workshop explains the approach and explores when it makes sense.

This session revisits what a Product Backlog Item represents, what an estimate represents and a common pattern in orgs 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:

This session discusses how experiments with estimation turned out, how you can uncover #NoEstimates in you organization, and what to do about it.

Estimates in software are ubiquitous. Some love estimates, some hate estimates. Woody asks questions. This is an invitation to find the right questions.

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.

This session explores estimates, why they are pervasive in the programming world, how they might be harmful, and proposes better ways to make decisions.

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

About the Author

Kent is a writer and product manager who helps product people deliver powerful internal products. He has IT and product development experience in a variety of industries including financial services, health insurance, nonprofit, and automotive. Kent practices his craft as Content Curator at Agile Alliance and shares his ideas and experiences at KBP.media. When not writing or product managing, Kent is his family’s #ubersherpa, listens to jazz and podcasts (but not necessarily podcasts about jazz), and collects national parks.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.