When teams get good at estimating, they can do it quickly and accurately.
When that happens, an organization can comfortably base decisions on those estimates.
But too often, teams you get hung up trying to create perfect estimates Here's the truth, trying to estimate perfectly does more harm than good.
That's why in this video I'm going to show you how to overcome the feeling that estimates need to be perfect.
To start, let's look at an example where the pursuit of perfect estimates caused real problems.
When I met Catherine, she was the 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.
The company had grown mostly by having very little competition over a few decades.
But lately, technology had enabled a lot of small companies to enter their space.
The company was struggling to hold onto market share.
As the company tried to protect itself against these new competitive threats, there was a real sense of urgency.
Catherine bore the responsibility to deliver results and deliver them on time.
When I visited, you could feel the tension just walking down the hallway.
One way Catherine tried to meet company-wide expectations was to hold team members to every estimate they gave.
When teams provided estimates, Catherine took them as guarantees, working those estimates into her plans and the reports she shared with stakeholders.
If team-members took longer than estimated, they got into trouble.
The first negative side effect of Catherine treating estimates as guarantees was that teams started padding their estimates so that they could be certain
they can complete the work in the time promised.
When shown these padded estimates, stakeholders chose not to have the team develop some of the functionality because it was so expensive.
Had stakeholders been given more accurate estimates without padding, some that work would have been prioritized into the product.
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 offhand way.
When they finally, ultimately got down to work, they hadn't left themselves enough time.
This is called student syndrome.
Remember those 10-page papers you had to turn in at the end of the semester for some class?
A full semester was more than enough to write that much, and we all knew it.
So most of us waited until a few days before the paper 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.
A final problem was that the padded estimates in Catherine'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.
If you've experienced these problems, you're not alone.
Many teams struggle to estimate well, and to treat estimates as what they are.
Estimates, not guarantees I want to share five practical solutions you can try.
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 member will give you a worst-case estimate.
This type estimate assumes everything goes wrong.
People who like to estimated 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 optimist estimate 10% percent of 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 estimations 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 cover the five types of estimates in detail in another video.
You can see it linked here and it is in the description.
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.
Once team member agree on the type of estimate they'll provide, you need to communicate this to stakeholders.
Unless you've told stakeholders otherwise, most will seem to think a team is providing estimates they will make 90% of time.
You need to inform them 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 that 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%
the of 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 percent of their 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 that same drive.
An estimate that can be beaten 100% of the time is a guarantee.
And a guaranteed will be much larger than a 50-50 or 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 that way before, but neither have most team members, which is why I suggested having this conversation with the
team first.
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 made 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 10 features by a given date, say that you will deliver 8 to 11. or instead of promising to deliver in five iterations,
say it will be four to six.
This leads to a fourth thing you can do to help a team that is getting hung up 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 write on an average, this 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.
With that few items, it's very possible that they could all be over or underestimated.
Fortunately, most agile teams have product backlogs big enough that this won't be a problem.
Second, you need an estimated approach that encourages team members to estimate low or high with equal probability.
A common problem is when a team underestimates much more frequently than they overestimate.
Teams that do this need to incorporate techniques that help balance over-estimating with underestimated.
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 2 1 2 4 and 8. I coach teams
to visualize values like that 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-poin bucket.
This creates a slight pessimistic bias.
Items are rounded up instead of rounded to the nearest value.
this helps counter the tendency many teams have to underestimate, and it means the team is more likely to balance under and overestimating.
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 teams to choose between estimates that are too close to one another.
I don' care how good a a is at estimatin, no team can tell the difference between 42 and 43 story points.
So make sure your team is using a set numbers that aren't far enough apart to matter.
Here's how.
Think about the percentage difference between numbers rather than the actual difference.
The difference in a one-point story and a two- point story is 100%. The differences 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 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.
These five techniques work well to reset the expectation 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.
Now, I want to hear from you, though.
Which of these techniques do you think will help you avoid the pursuit of perfect estimates?
Let me know in the comments.
And if you found this video helpful, please click the like button because that helps others find the video.
Remember to subscribe if