Story Points — A Proper Understanding

Some background…

While I no longer advocate for the usage of Story Points I realize that many organizations and teams still prescribe their usage. So I thought it would be a good idea to give a little background on Story Points, Relative Sizing and a proper way to use them.

Story Points

There is something that you, I and probably everyone else you know, and everyone else they know, are equally bad at doing. Any ideas? It’s estimating how long it will take to do something in units of time. It’s something that humans are just not good at doing. Anything more than a couple hours, forget it…

There are many reasons why which include:

• overestimating our abilities
• underestimating the complexity of tasks to be performed
• not accounting for interruptions that inevitably occur
• not accounting for dependence on others who may not share your urgency in completing the work
• not knowing ahead of time all of the additional, though necessary, work that will “appear” that we didn’t think of initially.

So it’s odd that we continually attempt, or are asked to attempt, to estimate non-trivial “work” in units of time. We won’t accurately know how long something will take until we are done doing it yet many business decisions continue to be made based on information we know we are not good at producing (see Einstein’s definition of insanity).

An agile based alternative to estimating work in units of time is by using a unit-less abstract measure known as “Story Points”. There is much discussion even within the agile community over what, exactly, contributes to the value that the team assigns as Story Points to a user story, but most will agree it’s a measurement of effort with perhaps some aspects of risk and uncertainty mixed in.

In order to keep this a (much) shorter article, I will skip over a lot of theory and explanation and just state that the values commonly used by Scrum Teams when estimating with Story Points are the modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40 and 100. Why not simply something like 1–10? Initially that was tried but it was found that teams spent too much time (waste) haggling over whether something was, for example, a 7 or an 8 when, in fact, it didn’t really matter — there was not a significant enough difference to spend the time to reach consensus, which leads me to the next topic…

Relative Sizing

There is also something that you, I and probably everyone else you know, and everyone else they know, are most likely very good at doing. And that’s relatively sizing an object against other objects. For example, which is larger, the dog or the house?

If you were to put a ruler over each photo you would find that the dog measures larger than the house but we all know, through inspection of other characteristics in the photos like horizon line & distance, that the house is actually much larger than the dog. Relative sizing, such as this, is something we are just really good at doing even when instruments that are accurate at “measuring” items say we are wrong.

You would (correctly) believe your “instincts” over the ruler. And it’s so built-in that you probably didn’t even realize you were calculating the perceived distance to each object through things like the size of the blades of grass and other aspects of the photos to determine the actual size of the house relative to the dog which is just a few feet from the camera.

We are similarly much better, though not always correct of course, at estimating the relative size of the effort required to complete one piece of work against another piece of work. For example, we could quickly conclude that the effort required to build a house for the dog is relatively a lot less than the effort needed to build the house in the other photo.

Putting it all together

In order to better understand how to use the combination of story points and relative sizing, let’s jump back about 900 years to the reign of King Henry I.

At that time, a “yard” was defined as the distance from your nose to your outstretched thumb. This caused many problems when, for example, people were trying to build a house and all of their measurements were different. Trust me on this one as a woodworker — always use the exact same tape measure when measuring each piece of wood used to build something!!! Now back to the story…

Thus King Henry declared that a “yard” was the distance between the tip of his nose and his outstretched thumb which established a standard unit of measure. Now the builders could better work together as they would know that their arms were a little more, or a little less, than the standard yard so now they had a common unit of measure.

Story points can be used in a similar way. They allow team members with different skill levels to discuss and reach agreement on an estimate through a common unit of measure. For example. let’s say that you and I decide to go for a run. I’m a very slow runner while you are a very fast runner. You point to a 5 mile trail we both know and say “let’s run that trail, it will take 30 minutes”. But I, being a much slower runner and having run that trail before as well, say “it will take 60 minutes”.

And so it goes: “30”, “60”, “no 30”, “no, it’s 60” — obviously this is going nowhere….

Now, we could compromise and say “45” but that would be worst thing we could do. 45 represents nothing to either of us and further compounding the issue is that we are both right. You can run the 5 miles in 30 minutes but it will take me 60 minutes. So again, trying to estimate in units of time has gotten us nowhere because we run (and work) at different speeds.

This is when we turn to more abstract measurements. We both agree it’s 5 miles, just not the amount of time it will take to run the entire trail. Story points serve the same purpose. They allow team members to communicate and agree on a measurement even when they have different skill levels and speeds of working. They have established a well understood common unit of measure.

Like our trail example, perhaps the team is discussing the effort to complete their first story and agree to assign it a value of “5” story points. For a fast programmer it may represent one day of effort but for another it may represent 3 days of effort. What’s important is that they both agree to call that story a “5”. Now we’re cooking with gas because we have a (baseline) story of “5” against which we can relatively size the effort of others stories. Perhaps when discussing the next story the faster programmer thinks it’s about the double the effort of the first and the slower programmer is also thinking similarly, or 6 days. Thus we assign that story a “10” since the team agrees it’s about double the effort of the first story. Or, since we’re using the Fibonacci sequence it would be either 8 or 13 (it’s not important which).

Like the distance from King Henry’s nose to his thumb, the team now has a common unit of measure that takes into consideration the performance rates of different individuals in the team.

I personally prefer Lean metrics for team usage over all forms of estimation. Story Points had their time but their misuse and abuse has rendered them dangerous. Simply using team data for understanding flow and forecasting is a far better practice.

If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.

Until next time!