When presenting program plans to senior leaders the topic of story points often arises when examining the plans of R&D teams using Agile, and I’m inevitably asked about the relationship between story points vs. hours. Senior management are looking for an answer along the lines of “one story point = 5.5 hours”, or something to that affect. Unfortunately for them, it just isn’t the case that we can answer that question. However, read on if you want to understand the real way in which story points and hours relate to each other…
Let’s start by defining a story point. A story point is simply an arbitrary measure used by Scrum teams. Each Scrum team can use its own story point range but a common one to use is: 1, 2, 4, 8, 16, defined as extra-small, small, medium, large, and extra-large. In order to know which story is 1 point or 4 points, the team needs to have its own baseline story. This story should be something the whole team can relate to. Once the baseline is in place all sizing is done in relation to this baseline.
In order to understand the relationship between story points and hours, let’s imaging that for a particular team you have tracked how long it took to develop every 1-story-point story. If you mapped this data into a graph showing time on the x axis and the number of stories on the y-axis, you would end up with a graph looking something like this:
What this diagram shows is that some one-story-point stories take a long time whilst others are much quicker for the team to complete, but overall we end up with a normal distribution. Now let’s draw the mean value onto this diagram:
This mean value is the average amount of time it takes to complete our 1-story-point story given our sample (as large as possible). It should now be becoming obvious to you why we can’t correlate a particular individual story with a number of hours, because individual stories can vary dramatically in time taken. However, on average one-point-stories converge at a single point.
Imagine you and I enter a running race to run 5k. If we didn’t know how fast either of us could run the race but we knew that the average time for 5k was 30 minutes, then this would allow us to take an educated guess that it might take us 30 minutes each to complete the race. On the day of the race, it might have taken you 20 minutes and me 35 minutes, so our estimate was just that, an estimate. Now imaging that there are 10,000 people running the same race, knowledge of the information above means we can estimate very accurately the total number of minutes it will take for everyone to complete the race (10,000 * 30).
The same problem applies to our 1-story-point story. If the velocity of our team is small (velocity equals the number of story points the team can complete in a sprint), let’s assume it’s 3, then it could be very difficult to predict if 3 single point stories could be completed inside a single sprint because our velocity is just too low to have any accuracy. We could end up with the following situation whereby each of the 3 stories takes longer than average to complete.
As you can see, just like in the running example, the higher the velocity of the team, the more likely we are to converge around the centre because the more one-story-point stories we can complete. Thus, it is only by completing a number of story points in a sprint that the team is able to provide any commitments around what can be done in a sprint, and why it makes no sense to correlate individual stories or story points with hours.
Finally, it should be clear to you that the distribution of actual time taken on 1-story-point stories and 2-story-point stories can overlap, as shown in the following diagram:
In summary, a story point is an arbitrary measure set by the team. Once the size of a story point has been baselined by the team then all future stories should be measured in terms of that story. It is impossible to say a single story point will take x hours, because individual story durations vary wildly, but when we have multiple stories (of the same point size) the average time taken for those stories will converge, which is what allows the team to commit to the amount of work they can complete in each sprint.