Rethinking how I look at story points.
I have been an agilest since 2009, and that means that my knowledge of scrum and agile has grown over time. Occasionally, I have to reconsider some ideas I took for granted. This week, I 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 hold up to 18 hours of work(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
Fn = [Story Point]
Where Fn is a number in a Fibonacci sequence.
Here is where the math gets essential. 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 mile size 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 time ranges get more significant as the story point increases. 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 sustainably. Finally, saying a story point is a range of time prevents managers and other business folks from 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 the ambiguous nature of the 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 or 18 hours of work. Now, you have a sprint with 39 story points 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 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 number of hours is the same! It is pretty cool, but here is where you, as a scrum master and project manager, can say you have more confidence in getting the work done. Thirteen-point stories are more risky to complete than a three-point story, and here is why. Let's 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, could you 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 will be more satisfied when they deliver 12/13 of the work than 2/3. Management and the people paying the bills will be more forgiving of the team when only 1/13 of the work is incomplete rather than 1/3.
Kedar’s computation shows that while the work is the same, the risk is much greater for fewer stories with more significant 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 longer or shorter 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 distance measure with time ranges than fixed time volumes. Making this intellectual shift will make estimating with story points more helpful.
Until next time.
Comments ()