Agile Estimating & Planning [2018] - Why Do We Need Story Points?

Episode 121 - 11 Apr 2018

CREDITS - Pointing hand by Denis Sazhin from the Noun Project

This is a map of the UK.

Notice anything strange about it?

Not really a fair question. I grew up colouring in pictures of this map at school, …

For those of you that didn’t

This is …. A more conventional view of the UK/

The reason this version of the map is distorted, is that it’s not a map of distances….

it’s a map of… time.

The map represents travel time.

More specifically travel time from London.

Every point on this arc is the same travel time from London.

(By the way this kind of map is called an Isochrone - in case you want to Google for a map of your own country or region.)

The strentching that we see in Scotland … the easyt…. And the southwest (check this) is a reflection that the transport system in these areas… is less well developed.

Which, I have to add is no bad thing. Would you build a motorway through this???

For planning a trip, this map is excellent: I get a true indication of how long it will get somewhere.

With no nasty surprises - Like the one I got the first time that I drove to the Highlands of Scotland.

But there are a couple of drawbacks to this map that you’ve probably already spotted.

This version represents travel time from - and, I suppose, to - London. Great for me, because I live in London.

But if I lived anywhere else… I’d need a different version.

There’s potentially an infinite versions of this map, each with a different starting point.

That’s one problem.

Another is that whoever put together this map made some assumptions about the mode of transport.

Is this a map of travel times for car travel… or via public transport?

The shape of the map will be different in each case.

It would be different again for walking… and for cycling.

So it turns out that this style of map isn’t as useful as it might look at first sight.

The conventional map turns out to be more useful… even though it doesn’t give me the number I want directly.

I want travel time,

But I’m very comfortable with “deriving” time from distance.

And I bet you are too.

We’re very used to starting with distance…

And then “transmuting” it into time.

If I ask you how long it takes to drive from Paris to Brussels…

You may not have the first idea.

If I tell you they are 314 km apart - that’s just short of 200 miles …

You can take a stab at it.

Here’s another example of transmutation

How long does it take me type 5000 words?

No idea? Me neither!

What if I tell you that I can type 50 words per minute?

(I can’t type anything like that fast… but it keep the maths easy)

5000 words, 50 words per minute.

100 minutes.

Words transmuted into time.

At this point I wanted to insert a third example of taking someitnh comcreate and transmuting it into time.

But I haven’t been able to come up with a good one. If you can think of one… enter it in to comments below.

Where was I

Distance…. Into time Words… into time The-great-example-you-just-thought-of into time.

It would be mighty useful something like these that we could apply to software development.

Trouble is.. Things in software that are ready to measure…

… have drawbacks.

Something like, say...

Number of lines of code Number of functions Number of commits into source control

These turn out to be bad choices:

Measure lines of code… and you get lots of useless lines. Meaire number the functions... and you get lots of useless functions Measure commits… and you get lots of meaningless commits.

In any case, these things all depend on coding - and coding comes to late in the process.

We want something that could be applied to planned work.

Enter the star of today’s show: the Story Point.

The Story Points are used to indicate the “SIZE” of each … can you guess? Yes. the size of each Story. Or Feature. Or task. Or piece of work. whatever.

(I’m INTENTONALY using the word “size” here in the vaguess and broadest sense. We’ll tie it down in due course.)

Story points share some of the properties of the “transmutable” things we looked at earlier.

ONE - If one particular Feature is a 5 Story Point feature.

We can each apply our own, personal transmutation.

I might think that I could complete a 5 point Story in 5 days.

A more gifted colleague might think that she could complete a 5 point story in 4 days.

TWO - Thinking now about a whole team of developers

If we know that we have a bunch of Features to create

And the total size of those features is 500 Story Points

And we know that the team builds - on average - 50 points a week

We can estimate that it will take the team 10 weeks to complete the features.


So far so good..

And now we hit a bump in the road.

Miles…. Kilometers…They are well-defined. They are concrete.

Story Points are I’m afraid, rather abstract.

There's no chunk of Imodium

(I know thats no longer the official definition… )

You can’t look up the “size” of Story Point.

Turns out….

The very next episode.

Never miss an Episode. Get "Development That Pays" direct to your inbox every week.