Why do we use Story Points?
Story points are often used as unit of estimation in Scrum projects. Why do we use them, and what is the advantage of story points over estimates in hours?
To answer that question, we should first look at the concept of Velocity. Because, having good story points allow you to work with a useful definition of velocity.
Let’s use an analogy to illustrate this.
Suppose you plan a holiday trip by car from Gouda (where I happen to live) to Nice in France. Google maps quickly shows you that the whole trip is 1351 km. A quick estimate for the duration of the trip is then easily derived. We estimate our average velocity to be 100 km/h (I usually drive a bit faster, but I’ve learned through experience that you are often hindered on the road, and usually don’t get much faster than this on average).
So, the total trip will take some 13,5 hours driving time. Let’s add some 2 hours of rest, and we can estimate our time of arrival.
So, now we have a plan for the project, we know the total size of the project (1351 km) and we have an estimate for the duration (15,5 hours).
During the trip, we want to track our progress.
Tracking progress in hours is stupid. If I hit a big congestion already at Rotterdam, and get stuck for 2 hours, my ‘progress’ in hours will be 2 hours, but my real progress is almost nothing. Tracking progress in hours will not help me to re-estimate my arrival time (except, when everything runs perfectly according to plan).
The only thing that makes sense in tracking progress is in tracking results. We could do this by watching the number of kilometres on the dashboard, but that feels a lot like micromanagement. You can’t keep your eyes on the dashboard all the time; you need to watch the traffic.
A much better way is to plan some milestones at regular distances at the track:
|Milestone||Distance (km)||Duration (h) cumulative|
- The milestones are not all at exactly the same distance. It would be nice that all major cities on my journey we at exactly 100 km distance, but, that’s simply not the reality.
- My estimates for distance are not exact, but rounded at 50 km. More exact estimates are not needed anyway. While driving, I never know exactly if I have reached Nancy or not. I may first reach the exit Nancy-north, then Nancy-centre and finally Nancy-south. If I arrive at any of these exits at roughly 6 hours after my departure, I know I am still on track. Estimating distances, and thus durations at a finer granularity will only cause me to micromanage my trip: “I am 3 minutes late!” which is only detracting me from my real progress.
So, back to software projects.
The velocity is the average number of story points that a team can deliver in a sprint (similar to my average speed of 100 km/h).
A story point is an indication of the size/duration of the tasks that we perform in a sprint. Stories should be small enough to give us sufficient milestones during the sprint to measure our progress. My personal taste is that 6-10 stories per sprint is a good number.
Fewer stories (and certainly less than 3) has some disadvantages:
- I cannot predict in any serious level of detail if I will achieve everything I have planned in this sprint
- There is a good chance that the last story in this sprint will not be completely delivered. If that happens, I have failed 50% or 33% of my sprint. That is a lousy result. If I did have 10 stories and missed the last one, I had a 90% result. Although not perfect, this is still a good result.
More stories means more administration, and we all hate administration, don’t we?
So, why do we use story points?
- We want to track business value (story points), not cost (hours). Tracking cost is useless, cost simply increases with time (our team is in place, their hours are consumed, their salaries are paid) regardless of any progress made.
- Estimating relative values (is this task twice as big as that task?) is much more easy for people to do.
- Story points lead to a useful velocity indication, which increases when we learn how to work smarter.
- The velocity will include all typical disturbances (getting coffee, regular meetings, typical interrupt levels) without the need to administer separately, so less bureaucracy.