Story Points vs. Hours

The concept of story points is a pretty integral part of agile project methodologies like scrum. In the same way you can find a myriad of explanations and variations of scrum, there are countless explanations of story points. The most important principle to embrace is that it is important that story points have a certain clear meaning for your organization much more than it is that you agree with any particular definition you find. That being said, having experienced tremendous success on projects that used story points, I want to offer my take in hopes it relieves some confusion or anxiety about the concept. 

"Well, story points are not NOT hours"

As a company, we were having a discussion about how story points will be used, which included the requirement that every task in our project management tool would have a story point value assigned to it as a representation of the anticipated effort. As is often the case for people new to using points, the concept of "representation of anticipated effort" led to the natural conclusion that story points are just an abstract representation of hours. As such, it was natural to want to determine the conversion formula, something like: 1 story point = 4 hours.

At that point I insisted adamantly that "story points are absolute NOT equivalent to hours!" A colleague in the meeting, also experienced with using points in project management, replied, "Well, story points are not NOT hours either!" Those were both correct statements.

Sound confusing? At this point, it may seem like I've just described a paradox. Are story points hours or not? The answer is a resounding - "exactly!" Since story points are used to represent anticipated effort, they obviously have some relationship to hours of work. However, to truly achieve the benefits of using story points, a person or organization must come to understand they are more than just hours.

Story Points = Hours x Risk Factor

The way I personally describe points is that they represent both an estimate of hours needed for the task AND the risk of inaccuracy of that estimate. That could also be expressed as an estimate of hours AND the confidence that estimate is accurate. I might say I think a task will be about a week of effort, but there are currently so many unknowns that I won't be at all surprised if it ended up taking twice that long. If I only said the first half of that sentence, imagine the unpleasant conversation I'd need to have with a stakeholder when my estimate turned out to be that grossly inaccurate! That uncertainty, or risk, is usually a direct representation of the complexity of the task.

I recently used the following chart as a way of illustrating this while still allowing for some standardized definition of the relationship between points and hours:

1 point = 1-4 hours
2 points = 3-10 hours
3 points = 5 - 15 hours
5 points = 2 - 5 days
8 points = 3 - 10 days
13 points = 5 - 30 days
21 points = 7 - 90 days

It is important to accept that project management using story points assumes, to some degree, that there is no "standard" for how points relate to hours. This is just my personal illustration to help make this point clearer and bridge the gap to hours for those trying to conceptualize points. It by no means should be considered as authoritative. Some purists would object to this much definition, but I offer this to make a couple points:

1. Any given point value represents a range of expected effort. As described in this article, you can think of each story point value as representing the peak of a bell-shaped curved, and thereby also including allowance for inherent inaccuracy.
2. As you can see from the ranges in my list above, as the story points increase, the size of associated duration range increases. This is the primary reason I say points must not be thought of as just a representation of hours. They are more directly related at the very low point values, but they are very much NOT at the higher point values.

Principles for effective story point use

• It is common to use the fibonacci sequence as the possible story point values. This sequence is not linear. Therefore, it is critical to avoid ideas like "each number represents 30% more effort than the previous number."
• It is useful to pick some threshold number in the sequence that never gets used because it essentially represents "It's a ridiculous, wild guess." In my example above, I would say no story ever gets assigned more than 21 points, and even using that number only represents that the amount of uncertainty prohibits accuracy.
• As the point values get higher, they become less about representing hours of effort and more useful as conversation starters. You can imagine the reaction of a stakeholder to the range represented by 21 points in my example above would be something like, "That's not at all useful for budgeting!" That is precisely the point of the higher numbers. The goal of the resulting conversation is to get sufficient clarity and definition of the project so it can be represented as a collection of lower-point tasks, which inherently have a higher accuracy.
• Actual results of hours worked per story point will vary significantly between tasks. Embrace the inaccuracy! The value of story points is in the aggregate over time, not the accurate prediction of the expected effort for a single task. In my experience, it has always been the case that even though the concept can sound very nebulous, and is therefore difficult for people used to thinking in terms of hours of effort, the amount of total points that gets accomplished in a period (per "sprint," monthly, etc.) ends up being surprisingly consistent.