Story Points Are Developer Astrology: The Collective Illusion of Agile Estimation

A 35-Minute Estimation Farce

An engineer recalls a scene from a sprint planning meeting: four engineers spent a full 35 minutes arguing over whether a ticket deserved 5 points or 8 points. The ticket in question? Adding a tooltip to a form field. One line of JSX, one CSS class — maybe 20 minutes of actual work.

And yet the team solemnly invoked the "sacred Fibonacci sequence." Someone said, "This isn't about time, it's about complexity." Another chimed in, "But effort is a factor too." The product manager nodded along as if the group were discussing astrophysics. They settled on 5 points, feeling productive — having accomplished absolutely nothing.

The author calls this phenomenon "Estimation Theatre" — a collective performance everyone participates in yet nothing useful comes out of.

How Story Points Went from Tool to Religion

Story Points were originally meant to rescue teams from the misery of bad time estimates. The logic sounds appealing: instead of predicting exact hours, use relative numbers to measure "complexity" and "effort." But the author sharply points out that story points didn't solve the problem — they just created a new religion.

The process goes like this: we assign numbers to work we don't fully understand, average out what each team member said, plot it on a chart, then pretend that chart can predict the future. It can't.

The author draws a comparison to astrology. Horoscopes use arbitrary symbols to make you feel like chaotic life is under control; story points use arbitrary numbers to make you feel like chaotic software development is under control. Both require faith, both ignore context, and both collapse the moment reality intervenes — an unexpected production bug, a sick kid, or a dependency that hasn't been updated since an ancient version.

---

The concept of story points originated in Extreme Programming (XP) and early Scrum practices, popularized by Ron Jeffries and others in the late 1990s. The core idea exploits a cognitive truth: the human brain is better at relative comparisons than absolute estimates — we struggle to say "this will take X hours," but we can more easily judge "this is about twice as hard as that." The Fibonacci sequence (1, 2, 3, 5, 8, 13…) was introduced because its increasing gaps reflect the reality that higher-complexity tasks carry exponentially greater uncertainty.

Yet the design assumptions quietly broke down in practice. Story points were meant to be relative and team-internal, but cross-team comparisons, quarter-over-quarter trend analysis, and performance management forced them into the role of "objective numbers." When an inherently subjective, relative measure is used as an absolute one, every inference built on top of it becomes systematically distorted.

---

When the Number Becomes the Goal

The sharpest critique in the article is how story points mutated from a "planning tool" into a "performance metric."

Once Velocity stops serving planning and starts measuring team performance, the whole system begins to rot: managers ask why velocity dropped, and teams start inflating estimates to protect themselves. So 2 points becomes 5, 5 becomes 8, and eventually no one knows what any number actually means.

The author delivers a cutting line: the only thing story points reliably measure is how long a team can argue about story points.

He also lists several common distortions:

• Teams spend more time estimating a ticket than completing it;
• Engineers deliberately sandbag — intentionally underreporting capacity so they can look like heroes later;
• Velocity charts get pulled into performance reviews.

"This isn't estimation," the author writes. "It's fear with a Jira license."

Uncertainty Isn't a Bug — It's the Work

The central argument of the article is a reframing of what estimation fundamentally is: uncertainty isn't a defect to be eliminated — it's the normal state of software development. We build software in the dark, learning as we go, and no amount of Planning Poker changes that.

This point deserves reflection from anyone who has been through an agile process. Estimates are never accurate not because the method isn't refined enough, but because the thing being predicted is inherently full of unknowns. Trying to fight uncertainty with more elaborate rituals usually just adds more theater — not more certainty.

Alternatives That Actually Work

Beyond the critique, the author offers concrete alternatives. The core principle: replace "guesses about the future" with "facts about the past."

Cut Work Small, Then Ship It

Instead of debating how many points a large ticket deserves, break the work down small enough that you can actually deliver something.

Measure Cycle Time

Track the actual time each piece of work takes from "started" to "done." Use that real data to build a genuine sense of your team's rhythm.

Use Throughput and Monte Carlo Simulation

Count how much work your team actually completes per unit of time. For more refined forecasting, run Monte Carlo simulations. The key: these methods are grounded in historical actuals, not a roomful of tired developers guessing numbers by feel.

The author's recommendation is blunt: Want to forecast? Look at what you actually shipped last month — not what you estimated, but what you actually finished. That's your data. Everything else is theater.

---

Cycle Time is a core metric in Lean Software Development: the actual elapsed time from when work formally begins to when it is delivered, excluding any wait time before it starts. Unlike story points, cycle time is an objective, after-the-fact measurement that doesn't depend on anyone's subjective judgment.

Monte Carlo simulation is a probability-based forecasting technique: feed in your team's historical cycle time distribution and throughput data, run thousands of random samples, and get a probability range as output — for example, "85% probability of completing 20 items within 10 weeks." Rather than promising a precise deadline, it honestly represents the range of uncertainty, which makes it more actionable than a velocity-based projection that only looks precise. Together, these form the backbone of data-driven delivery forecasting in Kanban systems.

---

Restoring Story Points to What They Were Meant to Be

The article doesn't end with an outright rejection of story points. Instead, it argues for a more pragmatic stance. If you like story points, keep using them — but be honest about what they are: a shared language for talking about uncertainty, not a commitment, a contract, or a prophecy.

The danger arrives the moment you treat a "5" as a promise. At that point, you're no longer estimating work — you're negotiating anxiety.

As the author puts it in closing: no one ships software by reading horoscopes. The value of this article isn't in offering a shiny new toolkit — it's in puncturing the collective illusion that many agile teams silently share, and nudging us back to the most basic engineering common sense: let your actual delivery data do the talking.