Agile Estimating and Planning
Today we’ll look at
3 keys to successful estimation
And we’ll see where Story Points fit in to the picture.
Welcome to Development That Pays my name is Gary Straughan
Welcome back to our series on Agile Estimating and Planning
If you’d like to catch up…
… you know the drill..
Key to Successful Estimating #1:
Get multiple estimates
Ideally, from different people
To err is human
but we can average out the “errs”
by asking multiple people to estimate
If we ask a group of 5 people to estimate the weight of this locomotive,
And get these results…
60, 140, 120, 120 again and 80
We could average them out
(60 + 140 + 120 + 120 + 80)/5 = 104
Which isn’t far off.
But things don’t always work out so cleanly.
Now that this group is warmed up, let’s test them again:
“How long does it take to get from Paris to Brussels?”
it’s the question we’ve asked last time
And if you saw last week’s episode, you know that I am
- quite literally - asking for trouble.
The estimates are:
4 hours, 1 hour, 2 hours, 2 hours and 4 days(!)
Whoa… that’s quite a range:
1 hour to 4 days.
4 days is 96 hours.
That’s a range of very nearly 2 orders of magnitude.
Huge.
What’s wrong with these people.
What’s going on inside their heads?
Let’s take a look.
The person that said 1 hour was thinking of going by aeroplane.
The person that said 4 days was thinking of going by bike
4 hours … that’s driving.
These two are in agreement:
Perhaps they have the same thing on their mind?
Train - makes sense
And finally… aeroplane!
Interesting.
This person has factored-in the time to get to the airport
which is sits north of Paris.
5 people estimating...
5 estimates
of 5 entirely different things!
Which brings us to the second key:
KEY #2 - Use Objective Measures
What if we asked them a different question:
“How FAR is it from Paris to Brussels?”
The results… are in:
150, 200, 260, 180, and 220 miles
This time the estimates are in board agreement.
they all of the same order of magnitude.
An estimate of 2,000 would be one order of magnitude different
And 2 orders of magnitude would be 20,000 miles.
Which will get you most of the way around the earth.
If we look inside their heads…
This time, everyone’s looking at the problem in the same way.
Everyone is using the same basis for their estimate
An OBJECTIVE measure, based on the map
In contrast to the SUBJECTIVE measure we started with: the travel time.
When we’re estimating in software development,
We want to avoid “development time” - which is a SUBJECTIVE measure.
Instead, we need and OBJECTIVE measure.
And the unit of measure of this “thing” is the Story Point.
Here’s a definition from Mike Cohn:
“Story points are a unit of measure for expressing
an estimate of the overall effort that will be required
to fully implement a product backlog item or any other piece of work.”
Mike goes on to say:
“Because story points represent the effort to develop a story,
a team’s estimate must include everything that can affect the effort.
That could include: The amount of work to do
The complexity of the work Any risk or uncertainty in doing the work
As we touched on last time,
the originators of Story Points felt the need to bring a new unit of measure into the world
But they’ve given us a measure that is ABSTRACT
You can’t look up the size of a Story Point.
However…
the absolute size of a Story Point doesn’t matter.
That comes about as a consequence
of our third and final rule.
Key #3 - Use Relative estimates (if possible)
The team we started with did a pretty good job
of estimating the distance from Paris to Brussels.
But everyone on the the team was either from France or Belgium.
So they were well-placed to do a good job on that estimate
So this time I’m going to take them right out of their comfort zone
To a place they've never been
Let's take them to the west coast of the United States
If we ask them how far is it from San Francisco to Los Angeles
They are going to struggle
Let’s give them one last try:
“The distance from San Francisco to Los Angeles
is ______ the distance from San Francisco to Fresno.”
Chances are that they’ll all say “It's TWICE as far!”
A very good estimate!
Do you think anyone here thought about miles or kilometres this time?
There was no need!
Because the question was RELATIVE!
Compared to any of the questions we’ve asked so far,
this one is super-easy!
Let’s try another one:
If I asked you which of these is heavier
You wouldn’t hesitate!
And you’d also be able to have a stab at
how many times this one is heavier than that one.
All you could do it without having a clue about the weight
- in tons - of either of them.
Seems we’re pretty good at estimating the relative sizes of things.
And that’s why it’s not a problem that a Story Point doesn’t have an absolute size.
In practice when we’re estimating the size of Features
we’re interested in the RELATIVE size of Features.
And it’s the relative sizing that’s behind the choice of the fibonacci series
But I’m getting well ahead of myself: that’s a tale for another day
That’s wrap up with a reminder of the three keys to estimating
In summary, three keys to ANY kind of estimating:
#1 - Get MULTIPLE estimates from different people
#2 - Use OBJECTIVE measures
#3 - Use RELATIVE estimates (if possible)
That’s it for this time.
If you enjoyed this episode, please give it a thumbs up,
Share it with your team
And click the logo for a new episode every Wednesday.
I look forward to seeing you again soon.