I hear from a lot of teams that they struggle to estimate well: “We’re really bad at estimating,” they say. They know the reasons to estimate product backlog items, so they want to get better.
Too often, though, these teams will attempt to improve by trying harder. They don’t identify problems in their approach and systematically fix them, they just try harder.
I’m a mediocre chess player. I’m not going to win more games by just trying harder. To win more games, I need to identify where I’m weak and work to improve in those areas.
A team that just “tries harder" to estimate well won’t change much. And eventually the futility of getting better by only trying harder becomes demotivating. At that point some teams throw in the towel and take an attitude that estimating is impossible so they won’t try.
Estimating is not impossible but it is challenging. Instead of giving up, try these 7 things that will help your team estimate better.
Before We Begin
Each of these tips is so essential to accurate estimates that, in most cases, I've written an entire blog or ebook on the concept (or a related concept) behind almost every tip. I've included links to those for your ease of use.
One more thing before we get started: If you know me, you probably know I’m a big fan of estimating in story points. Story points are an abstract relative measure of effort. I’ve definitely got story points in mind for these tips. But they can be applied just as well if you estimate in more traditional units such as person days.
Tip 1. Agree on One of Five Types of Estimates
The first tip for more accurate estimates is to make sure everyone agrees on the type of estimate being provided. If you are giving a really conservative, safe estimate but I’m giving a best-case estimate, we’re almost certain to disagree.
This tip is fundamental. If your team doesn’t talk about what type of estimate you’re making, the only way team members will agree on estimates is by luck.
A team can provide one of five possible estimates, as shown in the chart below. The chart shows the likelihood of being done at various times. The general shape of the curve indicates that there aren’t a lot of things you can do to finish something much earlier, but the long tail indicates there are a lot of things that could go wrong to really make something take longer.
- Single Most Likely Estimate: This is the highest point in the chart below
- Ideal Case Estimate: This represents something like a 10% chance of accuracy. Pretty much everything has to go perfectly for a team to finish in this amount of time.
- Median Estimate (50/50 Estimate): The team is just as likely to finish early as they are to finish late.
- Risk-Averse Estimate: This is the reverse of the ideal estimate. But the team has a 90% chance of beating the risk-averse estimate.
- Worst-Case Scenario Estimate: This is located on the far right of the chart. Team members probably won’t estimate this conservatively because that represents everything going wrong while working on an item.
I Recommend Median Estimates
Where on this chart should team members estimate? I think the median is best. I think it’s easy for estimators to conceptualize—it’s the point where something is equally likely to take more or less effort.
But the most important thing is to have that conversation with team members so they’re in agreement about which variety of estimate the team wants to use. Gaining this agreement gets rid of a lot of frustration team members feel when they have what seem like futile disagreements over an estimate.
Learn more about the types of estimates in "The Five Possible Estimates and Which One Your Team Should Use."
Tip 2. Create Relative Estimates by Analogy
The second tip is to estimate relatively by analogy. If you’re ever in an estimating meeting with me, you will never hear me ask, “How long will this take?” Instead I ask questions like, “What other backlog item is this like” or “Will this take more or less time than this other item?”
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, especially once a team has built up a large base of items to compare against.
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.
There is also some evidence that relative estimation by analogy is more accurate (“A Causal Model for Software Cost Estimating Error” & “Software Effort Estimation: An Exploratory Study of Expert Performance”
For more on the topic of relative estimation, read the online ebook Estimating with Story Points.
Tip 3. Keep Estimates Within One Order of Magnitude
Third, keep most estimates within one order of magnitude such as 1–10. Research has shown that we’re actually not that bad at estimating items as long as we stay within one order of magnitude. That’s why in the agile estimating method of Planning Poker, the majority of the cards are small numbers. We can estimate pretty well in that range.
If you need to estimate outside an order of magnitude—and there can be good reasons for doing so—build up to that gradually. Estimate a dozen or more items all in the 1–10 range then start reaching a little larger.
Don’t estimate some items from 1–10 and then go right to estimating something at 100. Instead estimate a few items that are a little too big—perhaps up to 20. Then maybe move up to 40.
Keep in mind, though, in many cases you’d be better off splitting work this big into multiple, smaller items and estimating those instead.
For more on estimating withing one order of magnitude, read The Best Way to Establish a Baseline when Playing Planning Poker.
Tip 4. Avoid Getting Too Precise with Estimates
A fourth tip is to avoid getting too precise. It’s just too hard.
It’s obvious you don’t want to estimate something as 3.47 story points, person days, or whatever unit you’re using. Less obvious, though, may be that you probably don’t want to use 3, 4, and 5 as valid estimates. It’s unlikely team members can distinguish between numbers this close to one another.
I pre-identify a set of values teams will estimate with. A team might choose to estimate using the powers of two 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. For example, if we’re using the Fibonacci sequence we would 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 time in product backlog refinement by removing the pressure to be perfect. By removing pressure, it also helps get team members to engage in the process.
Pizza is another example we can likely all relate to. My local pizza restaurant offers pizzas in 3 sizes: medium, large, and grand. That’s enough. I can tell the difference between those sizes. If they offered me pizzas in 15 different sizes between medium and grand, I wouldn’t be able to tell the difference.
And just as when ordering a pizza, round up when team members are debating between two sizes. If you’re trying to decide between a medium and a large pizza, order the large. If the team is torn between 4 and 8, go with the 8.
Odds are there will be some unanticipated work involved that will push the item toward the higher number when the team gets into working on it.
I cover the concepts of story point ranges and rounding up estimates in more detail in “Story Points Are Best Thought of As Ranges.”
TIp 5. Triangulate Your Estimates
Tip number five is to triangulate your estimates. The term comes from old sailing ships. A ship’s navigator could figure out the ship’s location by looking at two objects at different points on the horizon and drawing a line from each on a map. The intersection would be the ship’s location.
We triangulate estimates by comparing the item being estimated to at least two other estimates, ideally one that’s larger and one smaller. For example, if we are thinking of estimating something as 5, you want to find perhaps a 2 and an 8 to compare against. Ask the team if the proposed 5 seems about twice as big as the 2 and a little smaller than the 8.
If so, you’ve got confirmation that 5 is a good value for that item. Often, though, team members will want to change the proposed value based on the triangulation. If so, great! Triangulating has helped improve that estimate.
Read about triangulating estimates, and how you can access our Agile Mentors Planning Poker tool.
Tip 6. Avoid Anchoring
Tip six is to avoid anchoring. Anchoring refers to providing information to estimators that may unduly influence the estimates they are about to make.
To understand anchoring, imagine you’re in a store and see a shirt that was previously $40 now on sale for $20. The mention of $40 anchors you into thinking the shirt is worth that much. Logically, who cares what price a shirt used to sell for? Your purchase decision should be based solely on the current price. But that old price gets in our head and influences us.
One of the advantages of estimation approaches like Planning Poker is that each person provides a first estimate free from anchoring by others.
But anchoring can occur in subtle ways. A product owner may start an estimating meeting by saying something innocent-sounding like, “This meeting should go fast today. I only have five items that need estimates and they’re all pretty small.”
Saying the items are “pretty small” gets in estimators’ heads and it’s been shown that phrases like that can unduly influence estimates. So, to get the best estimates possible, coach people not say things like that in estimating meetings.
Anchoring is one of the reasons I avoid velocity-driven sprint planning. Read about why I prefer capacity-driven sprint planning.
Tip 7. Avoid the Middle Ground
Tip number 7 is to avoid settling disputes by choosing the middle value. A human bias known as the central tendency of judgment shows that we tend to favor estimates perceived as being in the middle of a scale.
If, for example, a team estimates with a Fibonacci sequence (1, 2, 3, 5, 8, and 13) it is likely that the middle values (3 and 5) will be overused as values.
The same effect can be present when team members are debating which value to use. Someone will often suggest settling in the middle as a compromise. While the middle value may absolutely be the best estimate, don’t settle there without a thought.
Encourage the estimators with the high and low values to make a case for their values before going to the middle.
Getting Better at Agile Estimating
Estimating well is challenging. But don’t throw up your hands. There are steps you can take to become better at it.
I’ve shared 7 tips for how I help teams improve. What other things have you done to improve your team’s estimates? Please share your thoughts in the comments because I’d love to read them.
And if you’re interested in understanding, or helping your team understand story points, check out our estimating with story points video course.
