Story Points Are A Reflection!

Last week Anthony Mersino published a blog entry titled Story Points – Love Them or Leave Them? He ended his blog entry with the question, “What do you think?” I know it will shock some of you, but I have an opinion. An opinion born from observation, research, and hands-on experience. Story points are specific to every team that uses them. I have used and still do use story points in some very specific scenarios. To answer Anthony’s question, over the years I have migrated into the “leave them” camp with a few caveats (we will tackle those later in the week). Story Points have a litany of problems including a myriad of definitions, they are a poor tool to compare performance, they are conflated with hours, and they institutionalize bias (see The Slow End Of Story Points for in-depth discussions on these points). In the last round of articles I wrote on story points, I did not address the basic conceit at the core of story points. Story points assume that teams need to size pieces of work in order to know whether the work is too big or too risky to accomplish in a specific period of time. That assumption is wrong for any team that has worked together for more than a sprint/iteration or two and breaks its work down, plans and commits to that work, and then use the results from that sprint or iteration to improve how they work. These steps are basic activities for an Agile team. The inspect and adapt feedback loop provides an experiential platform that negates the need to have a debate over Cohn’s Numbers or an entry on the Fibonacci scale. That time is better spent discussing what the work is that is being requested by the product owner and how that work is going to be delivered.

Shifting to a flow-based philosophy by focusing on throughput and cycle time is a replacement for story points that integrates measurement into the team’s workflow.   Throughput is the number of units of work (UoW) delivered per unit of time and cycle time is the amount of time per unit of work. Changing the focus to a flow perspective removes the artificial construct of velocity (average number of story points) and challenges the team to monitor and improve the flow of items they are delivering.

Story Points are not horrible, at least at a team level, assuming they are not equated to hours and assuming risk is addressed as part of relative size. However, those caveats almost never stay as a theoretical boogeyman over time. I see very few teams that do not succumb to conflating hours and points – as a matter of fact, I mentioned that was a bad idea and got yelled at today. It seems to be human nature.  As soon as a team starts thinking hours they almost always forget about risk. It becomes a cascade failure. Kahneman, in Thinking Fast and Slow, says humans attribute causality to events; story points and hours are a causal chain.

Story Points are not evil and they may be useful in some circumstances. But like most tools, at some point, they lose focus. They have outlived their usefulness, therefore, I will leave them when at all possible.