Story Points Are History

Forget planning poker. A prompt is all you need.

Apr 16, 2025

It was crunch time.

The CEO of a company I advise as part-time CTO had just asked me the one question you always dread of getting wrong:

> "How long will it take to deliver this feature?"

It wasn’t just any feature—it was one a prospective customer was demanding before signing a deal. The pressure was on. The team I was asked to lead already had a reputation of missing deadlines. Trust was shaky.

I couldn’t afford to give another loose estimate or point-based estimation. So I tried something different: I asked ChatGPT to lay out the entire project plan.

Not just tasks. I linked them to Architecture, Dependencies, Team Size and our Tech Stack.

I treated the output as my research baseline. Then I reviewed, challenged, and revised it before sharing with the stakeholders.

And you know what? It worked pretty well. The estimate was solid. The team delivered and we rebuilt trust with the business side.

Why Story Points Are History

Story points once made sense. They gave us a fast, lightweight way to estimate effort without the overhead of detailed planning. Planning poker and team discussions brought in the wisdom of crowds.

But today? That crowd lives in a machine. And it’s available 24/7.

Large Language Models (LLMs) have flipped the script. They’ve been trained on thousands of engineering discussions, delivery plans, and system architectures. When you ask them to break down a feature—especially if you know how to guide them—they don’t give you a guess. They give you a plan.

A Concrete Example: Estimating a Notification Feature

Let’s say we want to build a feature that sends an email to a teacher when a student submits an assignment. Simple enough, right?

We’re working in a Next.js app, with AWS SES for email. One Full-stack Engineer and one DevOps Engineer is who I could assign to the feature.

I start by prompting ChatGPT with something like:

In seconds, I get back a structured breakdown:

Then I review and update the architecture with a few more prompts based on how I’d like us to implement the feature, or what tools we currently have (to add more context), until I arrive at a point where I’m happy with the details. During the chat, I’m also getting to surface any gaps or things I may have forgotten to take into account (e.g., setting up permissions and getting email domains verified to avoid looking like a spammer).

Then with all this context in the conversation I ask for a time estimate:

Not only do I get an estimate, but I get back a day-by-day plan as well with module breakdowns, phases and rough deliverables. Plus some potential risks. Just with a basic prompt. Some things may be slightly off or optimistic—but it is 90% there and it takes my constraints into account. Then I can make a judgement call whether I want to add a bit more time for testing or prototyping for example. I opt for setting the team to deliver within the midpoint between the lower and upper estimate I got. I figured that if we have any delays we can offset them by using AI tools (e.g., Cursor) to assist the engineers to debug faster.

But the point is, a product manager and engineer could look at the plan, tweak it, and instantly understand what to expect. No translation from story points to hours. No abstract t-shirt sizing. Get specific…fast. It’s now possible. And documentable.

Here is the chat.

What Changed?

Overall, we were a couple of days late on our internal deadline (midpoint estimate) and 1 day sooner than the high estimate that we shared with business and that was because I didn’t account for someone having a PTO plus there was a national holiday. Oh well...

The CEO was happy and so was the Head Of Product.

The team had a shared blueprint.

And we didn’t use story points once.