Story Points: The Great Confusion
And why the agile community still can't agree on what they measure
Story Points: Are They About Size or Are They Hiding Time?
A recent discussion got me thinking about one of software development's most contentious topics: story points (or as I've come to call them, "sorry points"). Are they truly a unitless, relative-size measuring tool, or are they just time estimates in disguise?
The Theory vs. Reality
Mike Cohn, in his influential "Agile Estimating and Planning," describes story points as completely unrelated to time. This resonated with how I used them for years—ignoring time entirely and focusing purely on comparative effort.
Think of it like estimating the effort to paint rooms: the square footage of room A doesn't matter for estimation purposes. If room A is half the size of room B, it should take roughly half the effort to paint. Simple, clean, logical.
I coached many teams to think this way before eventually abandoning story points altogether (with considerable relief, I might add). But then I stumbled across something that shattered my understanding.
The Plot Twist
Years ago, I read a post by Ron Jeffries about the origins of story points that completely surprised me:
"So, as I recall it, we started calling our 'ideal days' just 'points'. So a story would be estimated at three points, which meant it would take about nine days to complete."
Wait. What? Story points started as time estimates? Or where they just ‘points’, not ‘story points’?
This sent me down a research rabbit hole, and what I found was fascinating—and deeply confusing.
The Literature Is All Over the Map
The more I dug into the XP and agile estimation literature, the more contradictory it became:
Extreme Programming Explained (first edition) proposed a simple 1, 2, or 3-point system, with larger stories requiring breakdown. But in the second edition, the authors pivoted to preferring real-time estimates.
Extreme Programming Perspectives introduced "complexity points" based on relative story complexity.
Extreme Programming for Web Projects went back to time, suggesting estimation in days (minimum half-day increments).
Extreme Programming in Practice advocated for ideal hours.
Planning Extreme Programming suggested "ideal time" measured in weeks, but then added this mind-bending caveat: "The notion of ideal time has little to do with time. Indeed some people like to use something like story points."
Extreme Programming Installed discussed "perfect engineering weeks" and used points merely as tags for stories initially estimated in ideal time.
Extreme Programming Applied offered two alternatives: ideal days or "craft units"—with each craft unit equivalent to one ideal engineering day.
And the creativity didn't stop there. In 1999, Joseph Pelrine proposed "Gummi Bears." In 2003, Joshua Kerievsky introduced NUTs (Nebulous Units of Time). Meanwhile, Martin Fowler aligned with Mike Cohn's time-agnostic approach.
The Takeaway
If you're confused about story points, congratulations—you're in excellent company. The agile community itself has never reached consensus on what these mysterious units should represent.
This inconsistency isn't just academic. It creates real problems in teams where half the members think they're estimating complexity while the other half are secretly calculating time. No wonder story point discussions often feel like everyone's speaking different languages.
Maybe it's time we stopped pretending there's one "right" way to think about story points and acknowledged what the literature reveals: this has been a mess from the beginning. The question isn't whether you're doing story points correctly—it's whether they're worth the confusion they create.