Perspectives on Estimating

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:

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

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

Estimates in software are ubiquitous. Some love estimates, and 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

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

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Kent McDonald

Kent McDonald

Kent J McDonald writes about and practices software product management. He has IT and product development experience in a variety of industries including financial services, health insurance, nonprofit, and automotive. Kent currently practices his craft for a variety of organizations and provides just in time resources for product owners and business analysts at and Product Collective. When not writing or product managing, Kent is his family’s #ubersherpa, listens to jazz and podcasts (but not…

Recent Blog Posts

Recent Posts

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Recent Agile Alliance Blog Posts

Post your comments or questions

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now