When teams get good at estimating, they can do it quickly and accurately. When teams create accurate estimates, their organization can comfortably base decisions on those estimates.
But too often, teams and stakeholders bog down in trying to create perfect estimates.
I think most people know that a perfect anything rarely exists, but that doesn’t stop organizations setting impossible standards when estimating.
But it’s worse than you might think: trying to estimate perfectly actually does more harm than good.
In this article, I’ll demonstrate why treating estimates as guarantees causes problems. I’ll then show you five ways to overcome the feeling that estimates need to be perfect in order to be dependable.
Case Study: How Treating Estimates as Guarantees Led to 3 Big Problems
To explain why the pursuit of perfection is a bad idea, let’s look at an example case study.
When I met Katherine, she was a senior vice president of a company with over $6 billion in revenue. She and her teams were responsible for a little more than half of that: $3B.
For a few decades, the company had grown mostly by having very little competition. But in the past few years, things had changed. Technology was enabling a lot of small companies to enter their space and the company was struggling to hold onto market share.
As the company tried to protect itself against these new competitive threats, Katherine bore the responsibility to deliver results, and deliver them on time.
When I visited, you could feel the tension just walking down the hallways.
I observed that one way Katherine tried to meet company-wide expectations was to hold team members to every estimate they gave. When teams provided estimates, Katherine took them as guarantees, working those estimates into her plans and the reports she shared with other stakeholders.
If team members took longer than estimated, they got into trouble.
Problem 1: Teams Began Padding Estimates
The first negative side effect of Katherine treating estimates as guarantees was predictable: Teams started padding their estimates so that they could be 100% certain they could complete the work in the time promised.
One immediate consequence of this estimate inflation was that when the stakeholders used the padded estimates to make decisions, they sometimes chose not to have the team develop some features because of the implied expense, ultimately harming the product. If the teams had given stakeholders more accurate estimates without padding, some of this work would have been prioritized into the product.
Problem 2: The Padded Estimates Were Still Too Small
A second problem was that, even with the padding, some estimates weren’t big enough. Team members knew the estimates were padded, so they frittered and wasted the hours in an off-hand way. When they finally, ultimately, got down to work, they hadn’t left themselves enough time.
This is called student syndrome. Remember those ten-page papers you had to turn in at the end of the semester for some class? A full semester was more than enough time to write that much—and we all knew it. So most of us waited until a few days before it was due to even start. And that meant some of us missed the deadline. Teams behave the same way when they pad their estimates. They wait too long, and then they fail to finish on time.
Problem 3: Trust Eroded
A final problem was that the padded estimates in Katherine’s organization created a lack of trust between managers and teams.
These problems all happened because leaders expected perfect estimates that could be treated as guarantees. When some estimates were inevitably overrun, the team suffered.
Five Ways to Help Teams & Stakeholders Treat Estimates as Estimates
If you’ve experienced these problems, you’re not alone. Many teams struggle to estimate well, and many give up on estimates altogether! These issues happen when organizations don’t treat estimates as what they are: estimates, not guarantees.
I want to share five practical solutions you can try.
Solution 1: Create a Shared Understanding of Estimate Type
The first is to create a shared understanding among team members about the type of estimate each is giving.
If you ask a team to estimate something, some team members will give you a worst-case estimate. This type of estimate assumes everything goes wrong. People who like to estimate the worst case are trying to provide an estimate that is safe—something they think they can beat 99 or 100% of the time.
Other team members may provide an optimistic or best-case estimate. This is often one in which estimators assume most things go as planned. And a team may only beat an optimistic estimate 10% of the time.
If you have some people giving best-case estimates and others giving worst-case estimates, no wonder they’ll struggle to agree. No wonder estimating takes longer than it should. No wonder some teams want to just stop estimating altogether.
Typically a Scrum Master or agile coach will get the team to talk through their differences. But before doing that, it’s critical to get everyone to agree on the type of estimate. I recommend having team members agree to provide the median estimate of the effort. Think of it as a 50/50 estimate—equally likely to be too high or too low.
Solution 2. Explain Team Estimates to Stakeholders
Once team members agree on the type of estimate they’ll provide, you next need to communicate this to stakeholders. Unless you’ve told them otherwise, most stakeholders seem to think a team is providing estimates they’ll make 90% of the time.
You need to inform that the team is providing median estimates and the work will exceed the estimate about 50% of the time.
Here’s how you can drive home the idea that an estimate is not a guarantee with your stakeholders.
Ask them how long it will take to drive to their favorite restaurant on a Saturday night. Be clear you want a 50/50 estimate. Let’s say a stakeholder estimates this as 30 minutes.
Next, ask the person for an estimate they are 100% confident in. This means if they drove to that restaurant on a thousand Saturdays, every drive would take less than that estimate.
If the person is good at estimating, they’ll realize that an estimate that can be met 100% of the time should be much larger than one that is met merely 50% of the time. If 30 minutes is the median estimate for driving to the restaurant, someone might say 90 minutes as the estimate they can beat 100% of the time.
If the person only increases the estimate a little—say from 30 to 45 minutes—ask them to consider everything that could possibly go wrong on the drive to the restaurant: car breakdown, tornado, road closure, a traffic ticket, Godzilla, or even all of these on the same drive.
An estimate that can be beaten 100% of the time is a guarantee, and a guarantee will be much larger than a 50/50 (median) estimate.
When you explain it this way, most stakeholders, bosses, clients, and customers will understand that estimates are not guarantees. They probably haven’t thought about it this way before, but neither have most team members⸺which is why I suggested having this conversation with the team first.
Solution 3. Share an Accurate Plan (Not a Perfect One)
Once everyone agrees on using median estimates and understands what that means, it’s time to take the third step to help your team avoid getting hung up on creating perfect estimates. And that is to give stakeholders an accurate plan, even though the estimates that make up that plan aren’t perfect.
Reasonable stakeholders aren’t going to get mad that some estimates turn out to be too low. After all, you’ve told them you’re using median estimates. What stakeholders get mad about is when the overall project is late.
The best way to add accuracy to a plan is to express the plan as a range. Instead of telling stakeholders you’ll deliver ten features by a given date, say that you’ll deliver eight to eleven. Or instead of promising to deliver in five iterations, say it will be four to six.
Solution 4: Get Estimates Right on Average
This leads to a fourth thing you can do to help a team that is getting bogged down by trying to create perfect estimates: Get estimates right on average.
Team members often obsess over estimating each item perfectly because they think that’s the only way to be right. It’s much easier and faster to instead be right on average.
Being right on average requires two things. First, estimate a large number of small things. This is necessary so that errors average out. You can’t have a product backlog of eight items and expect errors to average out. With that few items, it’s very possible that they could all be over- or under-estimated. Fortunately, most agile teams have product backlogs big enough that this won’t be a problem.
Second, you need an estimating approach that encourages team members to estimate low or high with equal probability. A common problem is that a team under-estimates much more frequently than they over-estimate. Teams that do this need to incorporate techniques that help balance over-estimating with under-estimating.
Most agile teams estimate with a predefined set of values such as the Fibonacci sequence (1, 2, 3, 5, 8, and 13) or powers of two (1, 2, 4, and 8).
I coach teams to visualize those values as buckets. Each bucket can hold estimates up to its size. With five- and eight-point buckets, that means items that are six or seven points go into the eight-point bucket, since a six-point item would overflow a five-point bucket.
This creates a slight pessimistic bias—items are rounded up instead of to the nearest value. This helps counter the tendency many teams have to under-estimate. And it means the team is more likely to balance under- and over-estimating.
Solution 5. Estimate with Numbers You Can Differentiate
A final way to help a team not get hung up on creating perfect estimates is helping them select the right set of numbers to use when estimating. Basically, don’t force a team to choose between estimates that are too close to one another. I don’t care how good a team is at estimating—no team can tell the difference between 42 and 43 story points.
So make sure your team is using a set of numbers that are far enough apart to matter.
Here’s how: Think about the percentage difference between numbers rather than the actual numeric difference. The difference between a 1-point story and a 2-point story is 100%. The difference between 42 and 43? Just over 2%.
This is why the Fibonacci sequence got popular for estimating. For numbers above three, each is roughly two-thirds larger than the previous. Many teams feel that’s a big-enough difference to be discernible. Other teams use a sequence like 1, 2, 4, 8, and 16, simply doubling each item for a 100% difference between values.
Accurate Plans Don’t Require Perfect Estimates
These five techniques work well to reset the expectations of estimates and how they’re going to be used. I’ve seen significant improvements with teams’ estimates just by having these conversations. They work by uncovering hidden assumptions, and encouraging communication that can really help align the understanding of estimates, both for the people who want the estimates and those responsible for creating them.
If you’d like to help your team create more accurate estimates and plans, consider one of our private, public, or on-demand Estimating & Planning courses.
