Story Points

The weird, wonderful, confusing and often misunderstood world of the story point. I have lost count of the number of times that I have been in a meeting when the transition to story points has come up and a large debate and confusion has followed.

“How many days is a story point?”

“Do we divide story points between test and development activities?”

“Why don’t we just use hours to estimate?”

“What is a Fibonacci?”

Why should we estimate in story points

Humans are not that good at estimating things in actual size, whether that be measuring something in minutes, metres, decibels, centimeters, kilometres, miles……… you get the idea. We just aren’t good at doing it, have a go now.

  1. Picture 4 dogs, Labrador, Dachshund, St Bernard and a Springer Spaniel
  2. Now give me the precise measurements for each of these?
  3. How precise can you do it? By weight in lbs? By length in cm?

I’m guessing that unless you are Rain Man that you are probably out from your guess, but what if I asked you to now put these dogs in order of size. Have a try now……….

I’m thinking small to large, Dachshund > Springer Spaniel > labrador > St Bernard? Well that was much easier, we may have some disagreement around the Lab and the Spaniel but they’re very similar in size and that’s ok, we can agree that quite easily but much more difficult it come to an agreement on precise measurement. The important thing here is that we can compare the dogs without their actual size. Okay now I bring in a Shih Tzu dog, can you easily put this into the order of our dogs?

We use relative sizing throughout our daily lives, think of coffee, strength is often depicted by number of beans on the jar, do you have a precise strength measurement? Can you tell how much stronger a 1 bean is that a six bean? You can workout that you like a medium coffee so you would go for the 3 bean one. All this without precise measurement. Don’t like coffee huh? Curry? Spicy food? this is often depicted by the number of chilli’s, same principle.

So what did this prove

We’re not very good at absolute measurements but we are really good with relative measurements.

How many times have you estimated some software task in hours and got it right? How many of you have estimated something as 1hr 15m? Really!? Who has said it will be x if I do the work but maybe y of someone else does the work?

So here is the thing, we want an abstract way whereby the whole team, developers and testers (the people performing the work) can have a common understanding and way to estimate how big pieces of work actually are relative to each other. Hmmm so lets take the dog example from before we could estimate the pieces of work as different dogs, a Labrador pieces of work is much bigger than a Shih Tzu or we could assign them some values:

Dog Points
Shih Tzu 1
Dachshund 2
Beagle 3
Labrador 5
Newfoundland 8
Great Dane 13

Now we can take this scale which is from the Fibonacci scale and use this to score pieces of work relative to each other. What teams usually do is to set a baseline with a simple piece of work and call that a Shih Tzu, I mean 1 point, then you can estimate the work based on that.

Typically with Scrum the numbers used will be 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. The higher the story points the less accurate the estimation is. It will be important to breakdown stories so that you can fit them into sprints and get them into a shippable state by the end, there will be another post about that.

Conversations & Discussion

What you will find if you start trying to estimate work with story points is that it gets a good conversation going between the developers, testers and product owners. This conversation and discussion in so important and its one of the great benefits of using story points. Teams should use a planning poker game (which is outlined in another post) to facilitate the story point scoring. This will result in people justifying their estimates, having more conversation about the work item and getting a better shared understanding of the work.


Now this will take a few sprints but what you want to do is get a feel for how many story points you can achieve within a sprint, you won’t know when you start your first sprint but you should get a feel of how much work you can commit to when you plan your sprint. After a few sprints you will be able to take an average and get an idea of how many story points you can achieve, this will help with planning and can indicate what can get done within upcoming sprints.


Dont get too bogged down with what is right, just get the conversations going about the work items. Make sure you agree as a team what the points are for work items and get everyone’s feedback. Promote discussion and if you’re struggling to agree or come up with an estimate then perhaps there isn’t enough information and understanding of the requirement.

Don’t have PO’s, PM’s or anyone outside the Scrum tream estimating. The Scrum team own the estimates and you want consistency. A PO or PM will most likely underestimate and don’t really have the understanding of what effort is involved.

More on self organising  teams and moving away from command and control in another post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s