
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.
June 5, 2019 at 7:22 pm
Tom, you referred to story points as not evil and not horrible, which is not very complimentary. When you say they have outlived their usefulness, does that apply to all applications of story points? I wonder if new teams benefit from story points and at some point they outlive their usefulness to a particular team.
June 11, 2019 at 5:46 am
[…] Story Points – Leave Them, Don’t Love Them Written by: Thomas Cagley […]
July 28, 2019 at 9:11 pm
[…] 558 will feature our essay Story Points – Leave Them, Don’t Love Them. I use them when needed but I am becoming less enamored with story points every […]
August 4, 2019 at 9:58 pm
[…] 558 features our essay Story Points – Leave Them, Don’t Love Them. Story Points are not evil and they may be useful in some circumstances. But like most tools, at […]