Story Points and the Pythagorean Trap.
Pythagoras, the Greek philosopher and mathematician, is best known for his eponymous theorem, a foundational concept in geometry that still underpins mathematics today. His insights into the relationship between the sides of a right triangle have cemented his legacy as one of history’s great thinkers.
But Pythagoras’ fascination with numbers went far beyond geometry. He believed that numbers held profound truths about the world. In his time, he and his followers applied numbers to places where they didn’t intuitively belong, trying to assign numerical values to concepts like virtue, beauty, and harmony. They were convinced that numbers could reveal hidden patterns, unlocking deeper insights into the fabric of reality.
Pythagoras felt that by assigning a number to something, that number could imbue the object with meaning and significance. This would mean that if you manipulate the numbers, you gain insight into the objects themselves. And while Pythagoras was successful in some domains, his attempts to quantify the unquantifiable fell short.
Reaching for precision in an ambiguous world.
Centuries later, the software industry grappled with similar challenges but in a different context. Unlike the physical world of civil engineering, where materials can be counted and weighed, software development exists in the non-material realm of knowledge work. Estimating tasks in this domain is inherently complex because we're dealing with abstract concepts, novel problems, and rapidly changing technologies. The industry has long struggled to find effective estimation techniques for this formless and ever-evolving landscape.
Methods like ideal days, lines of code, and even "kilo-lines of code" (KLOC) were introduced in an attempt to quantify effort with pinpoint accuracy. However, these approaches proved inadequate. Time and code metrics alone couldn't capture the complexities of building something new or adapting to change.
Story Points: A promise of simplicity, lost in translation.
The Agile movement rose to challenge these dysfunctional estimation methods, bringing a fresh approach through relative estimation techniques. The beauty of relative estimation lies in its simplicity: instead of guessing how long a task might take in absolute terms, we focus on comparing tasks based on factors like effort, complexity, and size. Techniques like Wideband Delphi and the wisdom of the crowd already existed, using the collective insights of a group to estimate relative sizes. But it was Mike Cohn’s introduction of story point estimation that popularised this approach, offering a framework that seemed to provide relief from the obsession with precision.
Story points, by design, are unitless. They are meant to represent relative effort and complexity, freeing teams from the rigidity of estimating in days, hours, or lines of code. The idea was straightforward: focus on relativity rather than precision, and estimate a task’s “size” in terms of its relative demands rather than time. This approach, theoretically, should have shifted our attention from granular accuracy to the bigger picture of delivery, complexity, and capacity.
The misuse of Story Points.
However, despite the good intentions, story points fell into what I call the "Pythagorean Trap." Just as Pythagoras attempted to assign numerical values to abstract concepts in hopes of gaining deeper insights, project management took this idea of unitless numbers and stretched it beyond its intended utility. Story points, although designed to avoid the dysfunction of strict time-based estimates, were quickly turned into numbers to be added, subtracted, divided, and transformed into formulas.
The human inclination to impose precision onto numbers took over, leading teams to assign specific meanings to story points and use them as 'velocity' metrics. Before long, we saw teams calculating their progress as x points = 1 day, turning story points back into exactly what they were meant to escape: yet another metric of time.
领英推荐
And why does this happen? Because when we see numbers, we see precision. We are compelled to treat numbers as if they are exact, especially in contexts where accuracy feels scarce. It’s a trap rooted in human psychology, a belief that because we’re dealing with numbers, we can and should seek measurable, accurate forecasts. But story points were never designed to be predictive; they were meant to allow relative comparisons, nothing more.
Why Story Points are predisposed to misuse.
The use of numbers in story points makes them inherently prone to misuse. Where non-numeric alternatives like T-shirt sizes (S, M, L) resist this kind of numerical manipulation, story points seem to invite it. T-shirt sizes force us to think in terms of relative size alone, not as units that can be averaged, multiplied, or mapped onto time. Story points, though meant to be unitless, fall victim to this numerical allure, our perception of precision blinds us to their actual purpose.
As a result, story points have arguably created more dysfunction than they set out to resolve. The temptation to measure, quantify, and correlate has made story points a victim of their own abstraction, a casualty of our collective obsession with numbers. The inherent ambiguity that story points bring should be their strength, yet it is often treated as a flaw.
Looking beyond the numbers...
Story point estimation may have begun as an attempt to correct the dysfunctions of overly precise project estimation, but its reliance on numbers makes it vulnerable to those very same dysfunctions. The Pythagorean dream of reducing complexity to numbers is as alluring as it is flawed, leading us down paths of false accuracy and misplaced confidence.
While math is a universal language that interprets so much around us, numbers applied to domains for the sake of imbuing them with meaning can end up misleading us.
Though I wouldn’t throw story point estimation out entirely, doing so would be akin to throwing the baby out with the bathwater, I believe it’s more often misused than used as intended. Admittedly, there’s a larger conversation to be had about why we estimate in the first place and what the alternatives could look like. But perhaps, by recognizing these pitfalls, we can step out of the Pythagorean Trap and focus on the conversations that matter most: understanding complexity, delivering value, and managing risk without the illusion of precision.
At Agilitie, we believe in partnering with organisations to deliver sustainable, people-driven transformation. Our approach focuses on empowering teams and creating environments where innovation and long-term success can thrive. If you're looking for meaningful change that lasts, we’re here to help.
#PrecisionParadox #StoryPointDilemma #HumanBehaviorInAgile #PythagoreanTrap #IllusionOfAccuracy #RelativeEstimation #CognitiveBias #AgilePsychology #EstimationPitfalls
Delivery, Coaching and Transformation
2 周Great points and something that is rarely spoken about these days. I would add the lack of proper training around the ‘model’ of story points and its abstraction from time as a complex system, is poorly understood. If only people had a deeper understanding of the original intent. Leaders would better understand its a hidden internal system for teams to derive a rough timeline, allowing decisions to be made.
Cloud Practice Lead. Chief Technology Officer. Advisory, Technology Strategy, Consulting Services. AWS. Azure.
2 周Very well written and definitely something many of us have experienced... "understanding complexity, delivering value, and managing risk" - nailed it!
Practical agile delivery and transformation
2 周Good insight Nadir Khan. I’ve definitely seen this trap, and fallen in occasionally. Sadly I never got the chance to pilot the idea of comparing work to Marvel Villains or Happy Meals, to help people soften their grip on predicted dates without any information.