The Death of Story Points (And What Comes Next)

The Cargo Cult of Fibonacci

Story points have become the cargo cult of modern engineering.

Teams religiously assign Fibonacci numbers to tickets. They argue about whether a 3 is really a 5. They calculate velocity with decimal precision. They project future sprints based on historical averages. And then they wonder why their predictions look like abstract art.

Here's an uncomfortable truth: story points were designed for a world that no longer exists.

The original premise was simple: developers work at relatively consistent speeds, so measuring relative complexity (a 5 is roughly twice as hard as a 3) should yield predictable velocity over time. Establish a baseline, and you can forecast with reasonable accuracy.

That premise is now broken.

Why Are Story Points Dying?

Story points assume a stable unit: the same team, working the same way, at roughly the same speed. AI assistance broke that assumption three ways — estimates now vary wildly per task, velocity no longer predicts delivery, and historical baselines no longer transfer.

The AI Variability Problem

When the same developer can be 10x faster on Monday (with Copilot, a clear spec, and a familiar codebase) than on Tuesday (wrestling with a legacy system, debugging an AI hallucination, and context-switching between three projects)—what exactly does a "5-point story" mean?

It means nothing. The unit of measurement has become variable.

Consider a real example: A developer estimates a CRUD feature at 5 points based on historical velocity. With AI assistance, they complete it in 2 hours. The next 5-point story involves debugging a race condition in legacy code, where AI is useless, and it takes 3 days.

Both were "5 points." One took 2 hours, one took 24. Your velocity graph now contains data points that vary by 12x for the same estimated complexity.

The Meaningless Velocity Problem

DORA's 2024 report found that teams adopting AI coding assistants saw delivery throughput decrease 1.5% and delivery stability decrease 7.2%¹: more activity, less shipped value. Velocity measures activity rather than outcomes, which is why teams with high velocity often deliver less value than teams with moderate velocity.

When AI inflates activity metrics (more commits, more PRs, more "completed" stories), velocity becomes pure noise. The number goes up, but nobody knows what it means.

The Historical Baseline Problem

Story point estimation relies on calibration: "Last sprint we completed 40 points, so let's commit to 40 this sprint." But what happens when:

• Half the team just adopted AI assistants (velocity might spike)?
• The codebase you're working on is unfamiliar to AI (velocity might drop)?
• Your best estimator left and took their calibration with them?

Historical baselines assume consistency. AI destroyed that assumption.

What Replaces Story Points?

The death of story points doesn't mean the death of estimation. Three approaches work in the AI age: time-boxed experiments, outcome commitments, and continuous re-estimation.

Approach 1: Time-Boxed Experiments

Instead of estimating how long something will take, commit to what you'll attempt within a fixed time box.

The old way: "This feature is 8 points, which historically means ~4 days."

The new way: "We'll spend 2 days exploring this feature. At the end, we'll know if we can ship it or need more time."

This approach acknowledges uncertainty upfront. You're not pretending to predict the unpredictable—you're committing to learning quickly.

Approach 2: Outcome Commitments

Instead of estimating effort, commit to an outcome by a date—and let the team figure out how to get there.

The old way: "This epic is 40 points across 8 stories, so it'll take 2 sprints."

The new way: "We'll ship user authentication by Friday. Here's the minimal viable version, here are the stretch goals, and here's what we'll cut if needed."

This approach focuses on what matters (outcomes) rather than proxies (effort). It creates alignment about priorities and surfaces risks early: "If we can't get OAuth working by Wednesday, we'll ship with email/password only."

Approach 3: Continuous Re-Estimation

Instead of estimating once at sprint planning and never revisiting, update estimates as you learn.

The old way: "We estimated 5 points at planning, so that's the estimate."

The new way: "We estimated 5 points on Monday. By Wednesday we know it's actually an 8. That's valuable information—let's update our commitments."

This approach treats estimation as a tool for ongoing conversation rather than a one-time prediction. The estimate evolves as knowledge grows.

How Planning Poker Evolves

We built our planning poker tool to support these approaches—not because we think traditional estimation is always wrong, but because teams need flexibility.

For Traditional Estimation

Yes, you can still assign Fibonacci points. Some teams and some types of work still benefit from relative estimation. Stable codebases, experienced teams, well-understood domains—story points can work here.

But we've added safeguards:

• Anomaly detection: Sprint metrics run through z-score anomaly detection, so when velocity swings outside its normal range you see it flagged instead of buried in an average.
• Planned-versus-completed tracking: Sprint metrics compare what you committed to with what actually shipped, so estimation drift shows up sprint over sprint instead of at the quarterly reckoning.
• Outcome trends, not tool tracking: We never track who used AI on what. Sprint-over-sprint comparison shows whether your estimates are getting more or less reliable, whatever the cause.

For Time-Boxed Experiments

Instead of assigning points, estimate in time boxes. The Time (Hours) scale runs from 1 hour to 40, and custom scales let you define your own checkpoints:

• 2-hour spike
• Half-day exploration
• 1-day prototype

At the end of the time box, the team answers a simple question: "Can we ship this, or do we need more time?" This creates natural checkpoints without false precision.

For Outcome Commitments

Outcome commitments don't need special tooling. Define the outcome, set a target date, and decompose into milestones with go/no-go checkpoints. Where tooling helps is afterward: action item tracking and health scores show whether the commitment shipped and stuck.

The Conversation Is the Point

Here's what most teams miss about estimation: the estimate itself doesn't matter. The conversation does.

When your team argues about whether something is a 3 or a 5, the value isn't in reaching the "correct" number. The value is in surfacing different assumptions:

• "I think it's a 3 because we can reuse the existing auth module."
• "I think it's a 5 because the existing auth module doesn't handle our new requirements."

That conversation revealed a risk. The estimate is almost irrelevant; the shared understanding is everything.

This is why estimation ceremonies remain valuable even when the estimates themselves are noisy. The goal isn't prediction. The goal is alignment.

Communicating the Change

If you're convinced that traditional story points aren't working, you'll need to communicate this to stakeholders who expect "velocity dashboards." Here's how:

For Engineering Leadership

Frame it around predictability, not process. Leaders care about knowing when things will ship. Explain that velocity has become unreliable (show the variance), and you're adopting practices that will actually improve predictability.

Show, don't tell. Run a parallel experiment: track traditional velocity AND outcome commitments for two months. Let the data speak.

For Product Partners

Focus on what they care about: shipping dates. Product managers don't care about story points—they care about knowing when features will be ready. Outcome-based commitments give them better information: "We'll ship by Friday" is more useful than "We completed 40 points."

Make it about risk surfacing. Continuous re-estimation surfaces risks earlier. That's what product needs: early warning, not false confidence.

For the Team

Acknowledge the dysfunction. If story points have become an empty ritual, the team knows it. Admitting it creates trust.

Make it opt-in initially. Let the team experiment with alternatives on a few stories before committing to a full transition.

The Future of Estimation

Here's where we're headed:

Short-term: Estimation becomes adaptive. Teams use different approaches for different types of work: story points for stable, well-understood work; time-boxes for exploration; outcome commitments for high-priority features.

Medium-term: AI assists with estimation itself. Based on historical patterns, codebase complexity analysis, and similar past work, AI can suggest estimates—not as truth, but as input to the conversation.

Long-term: Estimation becomes less necessary. As deployment cycles compress and feedback loops tighten, the need for upfront prediction diminishes. You'll know if something is hard by working on it for a few hours, not by debating points in a planning meeting.

Story points served us well for two decades. They were the right tool for their time. But the conditions that made them useful have changed fundamentally, and our practices need to change with them.

What This Means for Your Team

If you're feeling story point dysfunction, you're not alone. Here's where to start:

1. Measure your velocity variance. If it's fluctuating more than 25% sprint-to-sprint, your estimates aren't predictive; they're noise.

2. Try one alternative. Pick a few stories next sprint and estimate them with time-boxes instead of points. See how it feels.

3. Focus on outcomes. When planning, ask "What do we want to be true by end of sprint?" rather than "How many points can we complete?"

4. Embrace uncertainty. The honest answer to "How long will this take?" is often "I don't know yet—let me try for a day and I'll tell you more."

The goal was never to assign the right number. The goal was to ship valuable software. If your estimation practices are getting in the way of that goal, it's time for them to evolve.

Sources