Rethinking how I look at story points.

Story points are not like coffee cups

I have been an agilest since 2009 and that means that my knowledge of scrum and agile have grown over time.  Occasionally, I have to reconsider some ideas I took for granted.    This week would like to review the notion of story points.

My change of heart came about when one of my developers Larry Gasik came to me and confronted me about how we treat story points.  Many scrum masters and people in the agile community treat story points as measurements of volume like cups at a coffee shop.  If a developer works six hours a day on code then three story points’ holds up to 18 hours of work or (3*6).  By the same logic a five point story can hold (5*6) or thirty hours of work.

I have been doing it wrong.  A story point is more like a measure of distance rather than volume.  This blog from Mountain Goat Software does a better job explaining this better than I can.  To calculate the “distance” of a story point it is the sum of difficulty and ambiguity rounded up to the nearest number on a Fibonacci sequence.  If I were to write a formula for this it would look like this.

Story Point = Difficulty + Ambiguity
F_n = [Story Point]

Where F_n is a number in a Fibonacci sequence.

Here is where the math gets important.  An Olympic runner can run a mile in under four minutes.  A middle aged man like me can walk that distance in about thirty.  The size of the mile does not change just the ability of the person to cover the distance.  So two people will take a different amount of time to complete a three point story.  So two people will take a different amount of time to complete a three point story.  Now we can use ranges of time.  In the case of three story points, on the low side (3*1) for one hour to complete a story point to eighteen hours or (3*6) on the high side.

This accomplishes three goals.  First, story estimates deal with ambiguity better because the ranges of time get larger as the story point increases in size.  Second the story point allows for better forecasting because developers who concentrate on story points and velocity can plan how much work they can handle in a sustainable fashion.  Finally, saying a story point is a range of time prevents managers and other business folks packing more work into a story point because it is not a fixed volume of hours.

By treating story points like units of distance instead of volume you eliminate numerous distractions in your agile practice.  Managers will not treat sprint estimates like quotations because of ambiguous nature of the amount of time it will take to do the work.  This also prevents a manager from placing more work into a sprint saying, “It was five story points and it only took you 20 hours so I am going to add about ten more hours of work to keep you busy.”

This helped me come up with something I call Kedar’s computation after my technical lead.  Story points also help reduce risk in a project. For instance, say your developers spend six hours a day coding.  The range of hours inside a story point is between one and six.  Following this reasoning three story points could take as little as three hours of work or 18 hours of work.  Now, you have a sprint with 39 story point’s worth of work.  The product backlog items in the sprint could be divided in two ways.  The first way is 13 three point stories.  The other way is three 13 point stories.  Doing a little arithmetic on the back of a napkin this is what you discover.

Given:
13 three point stories.
(3*1)*13 = 39 || (3*6)*13 = 234

Given:
Three 13 point stories
(13*1)*3 = 39 || (13*6)*3 = 234

The amount of hours are the same!  It is pretty cool but here is where you as a scrum master and project manager can say that you have more confidence in getting the work done.  Thirteen point stores are more risky to complete than and three point story and here is why.   Say the developers get stuck on a thirteen point story and fail to deliver it during the sprint.  The math looks like this below.

26/39 which simplifies to 2/3

Now do the same thing for the sprint with 13 three point stories.  The team gets stuck on a three point story.

36/39 which simplifies to 12/13

The team is going to be more satisfied with the work when they deliver 12/13 of the work than 2/3.  Management and the people paying the bills are going to be more forgiving of the team when only 1/13 of the work is incomplete rather than 1/3.

This is Kedar’s computation, which shows that while the work is the same, the risk is much greater for fewer stories with larger story point totals.  To go back to our runner analogy, the runner is completing smaller chunks of the race at a time and is more likely to complete the entire race.  We have a better means of tracking how far along the runner is during the contest.  It may take them a longer or shorter period of time to finish the race but the distance traveled is the same.  The only difference is that it has been divided into smaller laps.

This is why I have changed my mind about story points.  They are more a measure of distance with ranges of time rather than fixed volumes of time.  Making this intellectual shift will make estimating with story points more helpful.

Until next time.