Skip to content

Story Points – not a measure of effort in hours

February 3, 2013

Getting the people to use story points in agile estimation is easy. Making them not to think in hours is tough.

I’ve been struggling a bit on how to get people detach story points from time. Attending the Professional Scrum Developer class by Richard Hundhausen helped me think of ways on how to explain this.

The important keywords I got from Richard’s class are size and complexity. Story points should be a measure of size or complexity. There is a correlation between complexity/size with time but we can’t really say exactly how long it will take to complete something but only that a simple thing takes a shorter time compared to a complex thing. There are a lot of reasons that affect this i.e. familiarity with the system, the component or even the people building it. This is why we should use the empirical nature of Scrum to discover this.

Here’s one idea I came up with.

The Marathon

Which do you think will take you longer to complete?
a. 5km marathon
b. 10km marathon

Answer: b 😊

How many hours will it take you to complete a 5km marathon? 10km

Possible answers:
1. Duh … I don’t run marathon
2. My best time is x hours
3. Won’t know until I tried it

Using exact distance makes it easy to answer the first question. We know the farther the run the longer it takes to complete it.

The second question is a bit difficult to answer. There are a number of considerations
1. If you haven’t done it, you can’t really know. You may attempt to guess but it will most likely be off.
2. 10km run does not equate to 2x the time to run the 5km.
3. Even if you run the marathon, you know that each time you run it is a different story. You will tend to improve your time overall as you run more but the actuals are not always the same.

Based on the discussion above, I will relate the km distance to size or complexity and the run time as effort in hours.

There are a lot of unknowns in building software and doing it as a team adds to the unknowns. The answer is to try it out and discover your team’s velocity. The longer you build and keep the team together, you will expect your velocity to improve over time.

Velocity is the number of story points a team completes in a sprint. This value changes as you add/remove people to the team, update the definition of done, team’s familiarity with the system and its members etc. Velocity is expected to increase as you do more sprints (assuming you keep the team together). If you are interested to know how many hours it took for a story point to complete in a sprint, you can divide total capacity (in hours) by the number of story points completed. This by no means constant across different sprints but is a good input as you plan for the next sprint especially if you consider the historical data in the previous sprints.

Posted from WordPress for Windows Phone


From → Scrum

Leave a Comment

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: