The Death of Story Points - How AI Finally Makes Agile Work

If you’re a software developer who still insists on using story points, I hope you know how to drive a bus because your career is already over - you just don’t know it yet.

I’ve been a guest on a few podcasts lately, and almost every time, once the mic is off, the same question comes up: What do you actually think happens to software developers in the age of AI? And my answer is that the industry is going to bifurcate into exceptional winners who have been waiting all their careers for this opportunity and losers who’ve had a good run but their time is over.

What Agile was actually supposed to be

If you read the Agile Manifesto, you’ll see it is focused on people, outcomes, collaboration and responsiveness. It's short. It doesn't mention story points. It doesn't mention velocity. It doesn't mention sprint retrospectives. It certainly doesn't mention Jira.

The 2001 promise was simple: get close to your customer, ship fast, learn, ship again. Don't waterfall. Don't pretend you can spec a year of work in advance. Build in tight loops.

But in practice, the need for product managers, software architects, developers of different types, not to mention QA, infrastructure and security as distinct disciplines meant that being agile required massive communication and coordination. Most development teams adopted the Scrum framework, which is where many problems for commercially oriented software development emerged.

Corruption & Unaccountability Theater

The principles behind Agile have always been sound, but unfortunately, this good intention was corrupted by practices that had the effect of minimizing accountability while maximizing compensation in an industry with negative unemployment.

My favorite example of this is the concept of “story points”. These are a made up measure of time and effort that a developer guesses will be required to create a piece of working software. Now, you’d think we already had a way of estimating time - hours or days, you choose - but no, if you do that you’re making a commitment to deliver something by a certain date. And that accountability is uncomfortable, but because software developers have been in high demand, they were able to invent these “magic beans” of unaccountability under the guise of “agile”.

No customer has ever used a product and thought “you can really tell they used Fibonacci numbers in their pre-grooming meetings to story point this product”.

While it is correct to say that we can’t commit to a 6 month project plan because we need to be able to be agile and respond to the realities we learn as we go, not being able to commit to a couple of weeks of near term goals is a nightmare when you’re running a business.

The Productivity Problem

In addition to the unaccountability issues with story points, the other problem with Agile is the large amount of time developers spend doing things other than developing. Most Agile practices use grooming meetings where you go through the backlog and estimate effort using story points. You then put work into the sprint. You then do daily stand ups. You then finish the sprint with a retrospective and other “ceremonies”.

In a two week sprint, you’d think there are 10 work days per developer. But with the various ceremonies, you lose up to two days each sprint. Then you need to back out at least a day for PTO, then there’s other meetings and before you know it you’re down to only half the time spent developing.

Unlike the story point corruption, these ceremony practices didn't emerge to avoid accountability. They emerged because building software involved enormous coordination and communication friction.

Humans had to translate customer problems into specs, specs into tickets, tickets into code, code into tests, tests into deployments. Each handoff lost information. Each gap between roles required a ritual to paper over it.

The bottom line is that the effort required to take the insight, goal or objective and turn it into a working product was massive. But the exciting thing is that AI is already dramatically reducing the effort, and this means we can hope to actually be agile and productive.

What AI Actually Delivers

In the last month, I've personally shipped more working software than we used to ship with five times the developers in six months. That’s a 30x uplift. At WorkSights AI, building out our Continuous Performance Intelligence product, a set of three major features including autonomous AI Observer Agents (that have memory and learn) would have been a six-month engineering project a couple of years ago. In two days I built and shipped a full AI-powered chatbot so you can use WorkSights AI directly within Slack. This would have been unheard of just two years ago.

The bottleneck isn't execution anymore. The bottleneck is: do I understand the customer problem clearly enough to tell the system what to build, but also make sure the AI builds it properly?

While the second question comes down to experience and technical knowledge of architectures, security and more traditional code quality considerations (code reviews, tests, etc), the first part is where the real magic is, and amazingly, it brings us full circle 25 years later to the Agile Manifesto.

People over processes. Shipping working software. Really knowing the customer and being able to respond to change and rebuild or adjust without fear. And now AI can help us do all of that at least an order of magnitude better by banishing the Scrummasters and the Story Points.

When execution time collapses, most of the old apparatus collapses with it. You don't need a two-week sprint to make a bit of progress on something when that same thing can be shipped this afternoon. You don't need a velocity projection when the real bottleneck moved from "how much can the team produce" to "how well do we understand the customer." You don't need story points to protect you from accountability when you can tell someone "I'll have it on staging for you to play with by Thursday afternoon" and actually mean it.

Grooming meetings that might have made sense when things took a long time to build are now more about just coordinating who’s going to tackle what - no more Fibonacci number debates about sizing something when you could have built it in the time you used to debate it.

The retrospective compresses into shared learning about techniques for getting the most out of the AI, not trying to explain away why you didn’t hit your magic bean story point estimate and now we’ve got to negotiate a reduction in scope so users don’t quit our product because we’re late (again).

What's left is the thing Agile was always supposed to be: close to the customer, small loops, real accountability because there's nothing left to hide behind.

Human Judgment Still Matters

None of this is an argument for taking humans out of the loop. One engineering team I know keeps a file called HALL_OF_SHAME.md - the first instruction in their claude.md config is to read it before doing anything. It catalogues the times the AI tried to delete their Kubernetes cluster, nuke their production database, or sent them six hours down a rabbit hole of increasingly unhinged refactors.

Human in the loop is not optional. I don’t think it ever will be. AI amplifies your engineering culture - the good parts and the bad parts. Teams with weak judgment and a chaotic culture will ship weak code faster and confuse their users more. But teams with good judgment and a culture of excellence that is accelerated - not threatened - by AI will deliver at a pace unimaginable two years ago.

But this does mean that smaller teams can do a lot more than bigger teams, and scaling the team was where a lot of the friction came in. So, there’s going to be layoffs and companies are going to shrink while they are delivering more than ever.

The Ones Who've Been Waiting Their Whole Careers

Which brings me back to the bifurcation I opened with.

The developer who has spent a career “sticking to their lane” and asserting their “story point” estimates in grooming and proudly reporting “velocity” as if they were actually productive is going away.

But the developer who thinks like a product owner - who closes the loop between customer insight and shipped code, who can hold the whole problem in their head from "what does the user actually need" to "does this ship" - that developer has been waiting for this moment their entire career.

They were always the best engineers on any team I've ever hired. They always have a bias to action, they always have the instinct to ask “why” for the customer. They never used story points as a measure of progress. For twenty years these entrepreneurial developers suffered inside a ceremony-heavy process that rewarded things that didn’t matter to the customer or to the business.

Welcome to the Best Time in Software

I've been building commercial software for a long time, and made plenty of mistakes along the way. One of my biggest mistakes in the early days of Accelo was scaling our engineering team and thinking that would mean we could deliver more product with more people.

For the first time in my career, the thing we've been promising ourselves since 2001 is actually on the table. Get close to the customer. Understand the problem. Build it. Ship it. Learn. Build again. In a day, not six months.

That's Agile. That's what it was always supposed to be. And for what feels like the first time, we can actually do it in a way that makes both engineering and business sense.

So when those technical folks corner me after the podcast mic goes off and ask me fearfully what happens to software developers in the age of AI - that's my answer. The winners are the ones who've been waiting for this opportunity their entire careers. The losers are the ones who confused the ceremonies with the craft and got comfortable avoiding accountability because there were always five other jobs open for them.

Welcome to the best time in the history of software.