Story Point Estimates Are Best Thought of as Ranges

On This Page

Get Your Free Scrum Cheat Sheet

Get Your Free Scrum Cheat Sheet

Sign up below to receive this FREE reference.

When estimating with story points, most teams use a predefined set of values that doesn’t include every possible number. For example, teams commonly use powers of two (1, 2, 4, 8, 16,...) or a Fibonacci sequence (1, 2, 3, 5, 8, 13, …)

By intentionally leaving some numbers out of the set of acceptable estimates, teams avoid bogging down in discussions of, for example, 15 versus 16. Estimating to that level of precision would be extremely difficult and time-consuming, and most likely not even possible.

One of the questions I often get about story points is what to do if you can’t decide whether a particular product backlog item should be an 8 or a 13 (or a 3 and a 5). Part of the answer can be found by thinking about water buckets.

 

Suppose you have 10 liters of water you need to store. You also have an 8-liter bucket and a 13-liter bucket.

Which bucket would you store the water in?

The 13-liter bucket, right? Ten liters of water doesn’t fit in an 8-liter bucket. The water would overflow and spill out.

Extrapolating further, you’d use the 13-liter bucket for all amounts of water from 9 liters through 13 liters. Once you hit 14 liters, though, you’d once again need a bigger bucket.

And so it is with the values you choose to use when estimating stories. Think of each value as a bucket. A value bucket is used for all stories between that value and the next lower value.

For example, when playing Planning Poker many teams will use a modified Fibonacci sequence of 1, 2, 3, 5, 8, 13, 20, 40 and 100. The 13-point card should be used for any story the team estimates larger than 8 and no larger than 13.

That is, each story point value is implicitly a range--just like a bucket can hold a range of amounts of water. The trick is to choose the right bucket.

Choose the Right Bucket for Each Product Backlog Item

For accurate planning and estimating, teams need to understand that their job is not to put an estimate on a product backlog item. Their job is to put the story in the right bucket. Yes, I know that in both cases someone grabs a pen and writes a number on a story card. But the goal is to find a number (a bucket) just large enough to hold the whole story.

When estimating, ask the team to picture a set of buckets in front of them labeled 1, 2, 3, 5, 8, 13 and so on (or whatever sequence it uses). And then ask them to picture themselves throwing story cards into the buckets.

This helps team members move away from the feeling that estimates need to be perfect and precise. They don’t. Product backlog items merely need to be “thrown” into the right bucket.

Why Rounding Up Some Estimates Is Good

You might be concerned that this rounding up of estimates could lead to inflated or padded schedules. Let me explain why that usually won’t happen.

Consider a product backlog item that you believe should be 10 points. But you’re using the modified Fibonacci sequence I listed above and are following the rounding up strategy I recommend. And so, the bucket you “throw” the product backlog item into will be 13.

Next, let’s assume that at 13 points, the item is too big to bring into a sprint. And so the team splits it into smaller stories. Perhaps they split it into three smaller stories, which they estimate as 5, 5 and 2 points.

Notice what happened there with the numbers.

The three small stories add up to 12 points. That’s one less than the 13-point estimate you actually put on the larger story. But it’s two more than the 10 you really thought was the right estimate for the initial large story.

By forcing the estimate into the next larger bucket, you’ve improved the likelihood of accurately predicting the delivery date of this project.

If you had rounded down to the next lower estimate (8), the project would be 4 points late. If you had used your actual estimate (10), the project would be 2 points late.

Instead, by using the estimate values as buckets and rounding up, you’ve made it more likely you’ll deliver this project on time.

But couldn’t the 10-point story have turned out to really be 8 points? Sure. But it could also have been 14 or 15 or any other number.

Ranges & Rounding Up Are Good Tools for Estimating

Rounding up estimates doesn’t lead to padding or inflation--a topic I cover in another blog post, “How to Prevent Estimate Inflation.” Instead, rounding and ranges are a reflection of the uncertainty in estimates. Thinking of story points as a range of capacity-limited buckets reflects this uncertainty and will help create more accurate plans.

Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.