What are Story Points?
Story points are a measure of time (effort) – a key distinction is that story points are not (directly) a measure of complexity. Story points provide a method to estimate the time it will take to complete a feature, across a whole team, considering a multitude of factors:
1) Complexity of the user story
2) The team who are likely to perform the work
3) Associated risk / uncertainty
Why is measuring time important?
A team needs to know when they will deliver a solution. Let’s say you are working for a client who want a new website. They want that site delivered before Christmas so that they can take advantage of the festive season. Using story points, you are able to approximate the time it will take to complete a set of features across your team, so that you can see if you will be able to deliver all of them on time.
If you can’t deliver everything, then, because user stories are independent (i.e. they wrap a whole, encapsulated feature), you are able to prioritise the backlog based on the user stories with the highest impact. This ensures that you produce effective estimations and are also able to prioritise the high value features in your delivery.
Story points vs days.
Aha, but why not just use days? Everyone understands what a day is, so it is a good metric, right? Well yes… it is… and it isn’t.
Take running as an example – I know that I can run 10 Kilometers in 50 minutes at my best pace, but another member of my team can run that same distance in 30 minutes. So, when our manager asks us to estimate how long it will take us to run 10 Kilometers, what do we say? From my experience, it is 50 minutes… and from my friend’s experience it is 30 minutes. Ok, so we’re reasonable and meet in the middle – we tell our manager it will take 40 minutes to run 10k. But what we have just created is an estimation that is useless for both of us – I can’t meet that deadline and my friend will exceed it.
Instead, story points give us a time-related metric to more fairly estimate this task. We would use a base story of which a score was already agreed on to use as a baseline. Let’s say that we estimated a 1k run to be 1 story point. We could realistically say that a 10k run is in order of 10 times harder: maybe it is easier because you’d take a slower pace or maybe it is more difficult because it is a farther distance, how about the uncertaintity of a new route? We discuss and agree this is a 13 point user story. This number is agnostic, allowing any member of our team to complete the work and ‘claim’ 13 story points. It may take me 50 minutes to complete the task and my friend 30 minutes, but it is still 8 story points.
So what’s the relationship between story points and time?
The relationship between story points and time is a clever one. You allow the team to work for a few sprints, measuring how many user story points they are able to complete during the sprint. This allows you to forecast future sprints. E.g. if a team, on average, is able to deliver 160 story points per week, and the backlog has already been estimated using story points, then you can effectively estimate how long the work will take to complete, regardless of who in the team performs each user story.
“So, story points are about time—the effort involved in doing something. Because our bosses, clients and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty and complexity are factors that may influence the effort involved.” – Mike Cohn, Founder of Mountain Goat Software.