I hear from a lot of teams that they struggle to estimate well.
Often these teams will attempt to improve by trying harder.
They don't identify problems in their approach and systematically fix those problems, they just try harder I'm a mediocre chess player,
I am not going to win more games by just trying hard.
To win games I need to identify where I was weak and then work to get better in those areas.
A team trying harder to estimate well won't change much.
And eventually, the futility of trying to get better by only trying hard becomes demotivating.
At that point, some teams throw their hands up and take an attitude that estimating is impossible, so they won' t try.
Estimating isn't impossible but it is challenging.
Instead of giving up, try things that will help your team estimate better.
In this video, I'm going to share seven tips for getting the best estimates of story size.
If you know me, you probably know I'm a big fan of estimating in story points, which are an abstract relative measure of effort.
I've definitely got storypoints in mind for these tips, but the tips can be applied just as well if you estimate in more traditional units,
such as person days.
Our first tip 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 the best-case estimate we're almost certain to disagree.
This tip fundamental.
if your team doesn't talk about what type estimate you're making, the only way team members will agree on estimates is by luck.
There are five general types of estimates a team can provide.
Let's take a look at each.
This chart shows the likelihood of being done at various times.
The general shape of the curve indicates that there are not a lot of things you can do to finish something much earlier.
But the long tail indicates there ARE a LOT of thing that could go wrong to really make something take longer.
The highest point shows the single most likely estimate.
This is one of the five types of estimate a team could provide.
To the left of most-likely estimate is the ideal case.
That represents something like a 10% chance of being right.
Pretty much everything has to go perfectly for a teams to finish in this amount of time.
Next is median estimate, the 50-50 estimate – the team is just as likely to be finished early as they are to finished late.
Finally, we've got a risk-averse estimate out to the right.
This is the reverse of the ideal estimate, but the team has a 90% chance of beating the risk averse.
And way out there is a worst-case scenario.
Team members probably won't estimate this conservatively, because that represents everything going wrong while working on an item.
Where on this chart should team members estimate?
I think the median is best.
I thinks 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 member, so they're in agreement about which type of estimate the team wants to use.
Gaining this agreement gets rid of a lot of frustration team numbers feel when they have what seem like futile disagreements over an estimate.
Our 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 take more or less time than this other item?
Estimating relatively can be done more quickly, especially once a team has built up a large base of items to compare against.
There's also some evidence that relative estimation by analogy is more accurate.
Third, keep most estimates within one order of magnitude, such as 1 to 10. Research has shown that we're actually not that bad at estimating items as long
as we stay within 1 order or magnitude.
If you need to estimate outside of an order 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 to 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 40. Keep in mind though, in many cases, you'd be better off splitting work this big into multiple smaller items and
estimations those instead.
A fourth tip is to avoid getting too precise.
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 use 3, 4, and 5 as valid estimates.
it's unlikely team members can distinguish between numbers this close to one another.
My local pizza restaurant offers pizzas in three sizes, medium, large, and grand.
That's enough.
I can tell the difference between those three size.
If they offered me pizzas of 15 different sizes between medium and Grand, I wouldn't be able to tell that difference.
So don't get too precise.
Use a smaller set of numbers that you can distinguish.
This is why the Fibonacci sequence and powers of two have become popular estimated sequences.
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 four and eight, go with the eight.
Odds are there will be some unanticipated work involved that will push the item towards the higher number once the Team gets into working on it.
Tip number five is to triangulate your estimates.
This term comes from old sailing ships.
A ship's navigator could figure out the ship location by looking at two objects at different points on the horizon and drawing a line from each on a map.
The intersection of those two lines would be the ships location.
We triangulate estimates by comparing an item being estimated to at least two other estimates, ideally one that's larger and one the smaller.
For example, if we're thinking of estimating something as five, you want to find perhaps a two and an eight to compare against.
Ask the team if the proposed five seems about twice as big as the two, and a little smaller than the eight.
If so, You've got confirmation that five 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.
Tip six is to avoid anchoring.
Anchoring refers to providing information to estimators that may unduly influence the estimates they're about to make.
To understand anchored, imagine you're in a store and you 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 sure 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 today should go fast.
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 to say things like during estimating meetings.
Tip number seven 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 center of a scale.
If, for example, a team estimates with a Fibonacci sequence, one, two, three, five, eight, and 13, it's likely that the Middle values,
3 and 5, will be overused.
The same effect can be present when team members are debating a value, someone will suggest settling in the middle as a compromise.
While the Middle Value may absolutely be the best estimate, don't settle there without sufficient thought.
Encourage the estimators with the high and the low values to make a case for their values before agreeing on the middle estimate.
Estimating well is challenging, but don't throw up your hands.
There are steps you can take to become better at estimating.
I've shared seven such tips in this video.
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 StoryPoints, check out our Estimating with Storypoints video course.
The link is in the description.
If this video has been useful, click the like button.
And, if your new to the channel, subscribe so you don't miss out on future tips.
Thank you for watching and I'll see you next time.