I once sat in a sprint planning meeting where four engineers spent 35 minutes debating whether a ticket was a 5 or an 8.
The ticket? Adding a tooltip to a form field. One line of JSX. A CSS class. Maybe 20 minutes of actual work.
But we had to consult the sacred Fibonacci sequence. Somebody said, “It’s not about time, it’s about complexity.” Somebody else said, “But it’s also effort.” The product manager nodded like we were discussing astrophysics.
We landed on 5. We felt productive. We had accomplished nothing.
That’s estimation theatre.
Story points were supposed to save us from bad estimates. Instead, they gave us a new religion. We assign numbers to work we don’t understand yet. We average those numbers across a team. We put them on a chart. Then we pretend the chart predicts the future.
It doesn’t. It’s astrology.
Think about it. Horoscopes use arbitrary symbols to make you feel like the chaos of life is manageable. Story points use arbitrary numbers to make you feel like the chaos of software is manageable. Both require belief. Both ignore context. Both fall apart the moment something real happens—a production bug, a sick kid, a dependency that hasn’t been updated since 2017.
And the worst part? The numbers become the point. Velocity stops being a planning tool and becomes a performance metric. Managers ask why velocity dropped. Teams start inflating estimates to protect themselves. Suddenly a 2 becomes a 5, a 5 becomes an 8, and nobody knows what anything means anymore. The only thing story points reliably measure is how long a team can argue about story points.
I’ve seen teams spend more time estimating a ticket than doing the ticket. I’ve seen engineers sandbag sprints so they can look like heroes later. I’ve seen velocity charts used in performance reviews. That’s not estimation. That’s fear with a Jira license.
Here’s the thing: uncertainty is not a bug. It’s the job. We build software in the dark. We learn as we go. No amount of planning poker changes that.
So what actually works? Slice work small. Ship something. Measure how long it takes from “started” to “done.” Track cycle time. Use throughput. Run a Monte Carlo simulation if you want to get fancy. But stop pretending that a room full of tired developers guessing numbers is science.
You want to forecast? Look at what you actually finished last month. Not what you estimated. What you finished. That’s your data. The rest is theatre.
And hey, if you love story points, fine. Keep them. But call them what they are: a shared language for talking about uncertainty. Not a promise. Not a contract. Not a prophecy.
Because the moment you treat a 5 as a commitment, you’ve stopped estimating work and started negotiating anxiety.
And nobody ships software by reading horoscopes.
Top comments (0)