A few devs have asked me recently why we don’t use story points. For many, it’s the first time they’ve worked on a team that doesn’t use them. And yet we ship. Consistently.

That’s because instead of story points, we use deadlines.

Story points are like Dragon Ball Z power levels. Dramatic, sure. But they were arbitrary, inconsistent, and ultimately not very useful once the story moved on.

Deadlines are different. Deadlines are the real fight. They’re how the world actually runs.

Why Story Points Don’t Work

Story points weren’t a bad idea when they were invented. In the 2000s, teams had long development lifecycles and project managers demanding hour-based estimates that rarely held up. Deadlines were meaningless because requirements kept changing.

Story points solved two things:

1. Abstracted effort away from hours, factoring in complexity and uncertainty.
2. Encouraged discussion and shared understanding.

Tracking velocity also removed the dreaded “how many hours left?” micromanagement.

That worked 20 years ago. Modern software doesn’t work that way.

The World Has Changed

We stopped living in the feature factory. We’re solving problems. Long-range estimates matter less when you’re Continuously Delivering small increments.

CI/CD pipelines, automated tests, and observability dashboards show progress in real time. Why hide behind points when the work itself is visible?

Somewhere along the way, Agile became Scrum dogma. Everyone got indoctrinated. Two-week sprints, story point poker (cards sold separately), velocity charts, ceremonies on top of ceremonies. Some smart people even thought Scrum wasn’t strict enough, so they invented SAFe!

Somehow we forgot the point of all this Agile stuff is moving fast and delivering value.

Deadlines Force Discipline

Then I read Shape Up. Six-week deadlines. No endless grooming. Just: “The problem is X. What can we build in six weeks to solve it?”

It introduced the principle of “fixed time, variable scope”. The fixed time makes you focus, variable scope made you constantly weigh your options and apply tradeoffs. This changed your mindset from trying to endlessly build everything to actually focusing on what is the most essential.

Story points don’t do that. “This is a 3, that’s a 5, our velocity is 32”—none of it matters when the real question is: “Can we ship something valuable this month?”

But What About Accuracy?

People sometimes say: “But our estimates are accurate—historical data, Monte Carlo simulations, fancy Jira plugins.”

Sure, you can refine estimates, but software is messy. Requirements change. Surprises happen.

To be honest, all that effort into “better estimates” could be spent just building. And shipping. And learning from reality.

Deadlines Are Hard

Deadlines aren’t always easy. They feel real. Either you hit them, or you don’t. That’s what makes them useful.

We tried Shape Up. And we failed. Scrum is so institutionalised that it requires a lot of political capital and vision to follow through (probably a post for another time).

Scrum feels safe. Story points give the illusion of predictability. Executives love velocity charts. It feels like progress. Deadlines demand skill and empowerment. It takes an empowered developer to question the scope and debate whether an extra feature is really necessary. It’s easy to say: “We promised this feature by next Friday, work weekends if needed.” It’s harder to ask: “What can we realistically achieve by next Friday?” It takes trust and maturity for leaders to accept scope trade-offs.

But the hard approach builds muscle. Teams get better at cutting scope, making trade-offs, and shipping instead of endlessly polishing. I’d rather build that muscle than spend time debating whether something is a 3, 5, or 8.

We’ll Keep Doing It

In 2025, velocity doesn’t matter. Outcomes, time to learning, shipping matters.

Deadlines push us to deliver. They make scope cuts visible and almost necessary. They align teams with how the real world works.

That’s why we ship without story points. And why we’ll keep doing it.