Agile Estimating and Planning 2018 – FREE 3-Part Mini-Series – PART 1



Welcome to Part 1 of this FREE Mini-Series on Agile Estimation and Planning.

Watch out for Part 2 on Friday!

—-

if you’re watching this video I’m going to assume that you’re a fan of Agile

But are you a fan of all of it?

Whenever I survey my audience,

Agile Estimating and Planning always comes up as a major source of pain

Is lack of predictability the price we pay for “doing agile”?

Is “We’ll get there when we get there”

the very best that we can do?

Hi my name is Gary Straughan

Founder of Development That Pays

With 13,000 subscribers and more than a million views

it’s one of the biggest channels on YouTube – in the agile space

What you’re watching now is the first of a three-part mini-series

on Agile Estimating and Planning

Obviously that’s a huge subject, so we’re going to

start by looking at estimating estimating individual features

– the basic building blocks

So how can we improve our estimates?

There are three keys to better estimates.

The first key is …

Actually, it’s some quite a nice day

Should we walk to the river?

It’s only five minutes away. Let’s go!

[Music]

This is the River Thames

(It’s the one that flows through London)

Ah, that’s a slightly arkward:

it actually took more than seven minutes

for me to walk here – which is quite a lot

longer than my initial estimate of five minutes

Which is a shocker because I must have walked this route a thousand times

We humans have a horrible tendency to underestimate

It’s a well understood and much researched phenomenon

It’s known as the Planning Fallacy

it’s such a strong tendency that we “tend” to underestimate things

– even if we’ve done them many times before

Which brings us to our first key to better estimates

KEY 1 – Estimate as a Group

While we’re here, let’s give that a go

How long do you think it would take to get to that bridge

I estimate four minutes

unfortunately I can’t ask you for an estimate

but I’ve taken my own advice and obtained estimates from:

my neighbour Steve, and my youngest son Charlie

Steve estimated one minute. Wow.

And Charlie he reckons he can get there in 30 seconds

Hmm. That’s quite a range: 30 seconds to four minutes (= 240 seconds)

That’s a difference of opinion of almost an order of magnitude

What’s going on in these people’s heads?

Well, I can tell you what was going on in my head

I was imagining walking to that there bridge

My neighbour Steve is a semi-pro athlete –

he was imagining running to the bridge

My youngest son is not known for his running abilities

but when he’s on his bike he’s pretty hard to catch

What does this tell us?

Counterintuitive as it may sound, estimating in TIME directly

is usually a bad idea

Time, you see, is a slippery character: it’s highly subjective

As we’ve just seen, we’ll do better much better

by choosing a more objective measure

In the case of the bridge, the obvious choice is distance

Let’s give that a go

As luck would have it I also thought to ask

Steve and my youngest son for their estimates

The three estimates are: 130m, 140m and 160m

For those of you on the Imperial system, that’s 430′, 460′ and 520′

This time the estimates are much closer together

That’s largely because this time – unlike the first time –

all three people are estimating the same thing:

the distance to the bridge

The objective measure

We have our second key to better estimates:

KEY 2: Use Objective Measures

All we need now is the equivalent of distance

that we can use in software development

Something that’s objective – just like distanc

Lines of code, perhaps?

Or commits to a source control repository?

Well, both of those are objective measures

but unfortunately they’re a little too easy to manipulate

Turns out that a better choice is “effort” –

the effort required to build, test and release

the feature or story

Wrapped up in that measure of effort is:

– the amount of work to do

– the complexity of the work

– and any risk or uncertainty in doing the work

The most commonly-used unit of measure for effort is the Story Point

This thing the Story Point: it’s not an absolute measure like feet in inches or metres

There’s nowhere we can go to look up the size of a Story Point

But it turns out that’s not as big a problem as it might seem

We’ll go into detail about exactly why that’s the case

in Part 2 of this Miniseries – which will be ready for your viewing pleasure

on Friday. That’s Friday the 18th of May.

Keep your eyes peeled for that one

In the meantime, if you have any comments or questions

please let me know in the comments below

I look forward to seeing you on Friday

Cheers for now

source