How Can We Get the Best Estimates of Story Size?

I was recently interviewed for an upcoming agile textbook written by Sondra Ashmore and Kristin Runyan. They asked me questions regarding several areas of agile development and Scrum. Last week, I explored questions they had about the product backlog. This week, I'd like to tell you about the conversation we had about estimating.

The conversation began as follows: Estimating is really hard. How can we get the best estimates of story size?

Well, estimating is definitely hard. But there are a few things teams can do to help this process:

1. Keep estimates manageable.
2. Estimate in relative terms.
3. Bucket backlog items by story size.

1. Keep Estimates Manageable

Try to keep most estimates, or at least the most important estimates within about one order of magnitude, such as from 1-10. There are studies that have shown humans are pretty good across one order of magnitude, but beyond that, we are pretty bad.

That’s why in the agile estimating method of Planning Poker, most of the cards are between 1-13. We can estimate pretty well in that range. You can get acquainted with the Planning Poker method to help make estimating easier here.

2. Estimate in Relative Terms

Estimate in relative terms rather than absolute terms. Instead of saying, "This will take five days," say, "This thing will take about as long as that thing."

In my Certified ScrumMaster training class, we do an exercise where we estimate home improvement tasks. We start by agreeing on something small, but not the smallest, and perhaps calling that a 2.

For example we might decide that installing a new oven is a 2. All other items on the list can be estimated relative to this. Something that will take four times as long would get an 8, and so on.

Not only is relative estimating more accurate, teams can do it more quickly. With relative estimating, the team does not need to think of all of the sub-steps and estimate each and then add them up. They only need to find something similar and use the same estimate.

The next step is to use velocity to determine how long each of those things actually takes. Velocity is how fast the team is getting those product backlog items done. Since velocity is volatile, I like to look at data from at least five sprints to get a range.

3. Bucket Backlog Items by Story Size

It’s hard to estimate and extremely hard to estimate precisely. It’s good then, to make estimating easier by not requiring teams to put exact values on every item they estimate.

I like to do this by pre-identifying a set of values teams will estimate with. A team might choose to estimate using 1, 2, 4, 8 and 16. Another team might use the Fibonacci sequence of 1, 2, 3, 5, 8 and 13, which is my slight preference.

The numbers in these sequences can be viewed as buckets. Using the latter sequence we have a 5-point bucket and an 8-point bucket.

The team doesn’t have to precisely estimate how long a given product backlog item will take. Instead, the team has only to put the product backlog item into the right bucket: “Does this item belong in the 5-point bucket or the 8-point bucket?” (Or perhaps some other bucket.)

This saves times in estimating meetings by removing the pressure to be perfect. By removing pressure, it also helps get team members to engage in the process.

How do you make estimating easier within your agile team? I welcome your thoughts below.