Story Points Are Dead: Here's Why Agile Teams Should Move On

Once hailed as a cornerstone of Agile, story points now face growing scrutiny. Are they simplifying workflows, or are they holding teams back? Let’s dive into why it might be time to rethink their place in Agile estimation.

"I like to say that I may have invented story points, and if I did, I’m sorry now."

These striking words from Ron Jeffries, one of the creators of Extreme Programming (XP), underscore a growing disillusionment with story points as a tool for Agile estimation. Once heralded as a revolutionary way to measure effort, story points have instead introduced complexity, misguided priorities, and a focus on metrics over meaningful value.

My experience across multiple Scrum projects mirrors these critiques. Despite good intentions, story points often fail to deliver on their promises of improving estimation and workflow efficiency. Instead, they can create unnecessary complexity, encourage counterproductive behaviors, and shift focus away from what truly matters: delivering value.

This article explores why story points may not be the optimal tool for estimation, supplemented by personal insights and perspectives from industry experts like Ron Jeffries, who highlights the inherent flaws in story points in his piece, "Story Points Considered Harmful."


My Experience: When Story Points Failed

In one of the largest Scrum projects I worked on, we rigorously applied story points to every user story. Teams spent hours debating whether a task was a 3-point or a 5-point effort. What was meant to be a quick estimation exercise turned into a prolonged discussion. Ironically, this didn’t result in better estimates—our predictions about effort and completion dates were still frequently inaccurate.

Worse, story points became a metric of team performance. Management began tracking our velocity, using it as a yardstick to measure productivity. This incentivized behaviors like inflating story point estimates to make velocity appear higher, further disconnecting the metric from reality.

The final blow came when the team started focusing more on hitting our story point targets than delivering meaningful outcomes. Stories were sized and prioritized based on how they fit into our velocity goal rather than their contribution to business value. The process felt increasingly detached from Agile’s core principle: delivering customer value iteratively and incrementally.


What’s Wrong with Story Points?

What’s Wrong with Story Points?
1. Story Points Distract from Value Delivery

Story points focus on effort, not value. Teams risk prioritizing tasks that fit their velocity targets instead of those that deliver the most customer value. As Ron Jeffries notes, this disconnect leads to a gamification of the system where velocity becomes the goal rather than a tool to guide improvement.

2. They Add Complexity Without Clear Benefits

Assigning and calibrating story points often creates confusion. Teams spend significant time debating point sizes, which doesn’t necessarily improve estimation accuracy. Consistency across teams becomes a challenge, especially in larger organizations.

3. They Encourage Unhealthy Comparisons

Velocity, derived from story points, can easily be misused by management as a performance metric. Comparing velocities across teams or tracking increases in velocity over time undermines trust and places undue pressure on developers.

4. They Do Not Account for Variability

Story points assume a stable and predictable system, but the reality of software development is far messier. Unexpected dependencies, scope changes, and technical debt can make any estimation method—story points included—unreliable.


Evidence from Industry Experts

Ron Jeffries, one of the creators of Extreme Programming (XP), has been a vocal critic of story points. In his article "Story Points Considered Harmful", he argues that the obsession with estimating effort detracts from Agile’s focus on value delivery. Jeffries advocates for breaking work into smaller, manageable pieces and using simpler metrics like throughput (the number of completed stories) to guide planning.

Other Agile thought leaders, such as Martin Fowler, have also criticized story points for being prone to misuse. Fowler suggests alternatives like time-based estimation or even abandoning formal estimation altogether in favor of continuous delivery models.


The Core Question: What Are We Optimizing For?

At its heart, the debate about story points boils down to a simple question: what are we trying to optimize? If the answer is “delivering value to customers,” then story points may not be the best tool. They often shift focus to effort estimation and velocity tracking, sidelining value delivery.

By embracing simpler, value-focused approaches, teams can spend less time debating estimates and more time delivering high-impact solutions. My own experience has taught me that the best results come when we keep things simple, focus on continuous delivery, and prioritize outcomes over metrics.


Alternatives to Story Points

If story points aren’t the answer, what should teams use instead? Here are a few alternatives:

  1. No Estimates: Focus on breaking work into small, consistently sized chunks. Use historical throughput data to gauge how much work the team can complete in a sprint.

  2. Time-Based Estimation: While not perfect, estimating in hours or days can be more intuitive and directly tied to scheduling.

  3. Empirical Planning: Base planning on actual historical data rather than speculative point estimates. This approach relies on measuring cycle time and throughput to improve predictability.

  4. Flow Metrics: Use metrics like lead time, cycle time, and work-in-progress limits to optimize the flow of work rather than estimating effort.


Final Thoughts

When it comes to estimates, a thoughtful and pragmatic approach goes a long way. Share them only when necessary and always frame them as flexible approximations rather than rigid commitments. This transparency helps foster trust and collaboration with stakeholders while aligning expectations with the realities of software development.

Instead of fixating on metrics like story points, consider shifting focus toward meaningful delivery. Practical alternatives, like time-based estimates with built-in buffers, provide actionable insights for planning without overcomplicating the process. Stakeholders typically value realistic and achievable timelines that allow for flexibility in execution.

If you’ve struggled with story points in your own projects, you’re not alone. Perhaps it’s time to let go of the points and focus on what really matters: delivering value, one story at a time.

COMMENTS
Related Articles