Story points were invented with good intentions–and then slowly turned into a mess. Here’s what I’ve seen over the past decade, how I stopped using them, and what I teach teams now instead. This one’s practical, detailed, and a bit liberating.

Beyond Story Points: A Practical Guide for Grown‑Up Agile Teams

Story points aren’t the problem.

They were created with good intent. A soft way to guide planning without the stress and politics of time estimates. Ron Jeffries, one of the original authors of Extreme Programming, helped popularize them–and he’s said himself: he’s not angry about story points. He’s just sorry for the abuse.

And abuse is what we’ve seen. Widespread. Systemic. Across industries.

Still: if you’re using story points today, you’re not doing anything wrong. You’re on your journey. But if they’re starting to feel heavy, confusing, or political–this article is your guide to using them more wisely, or moving beyond them entirely.

---

Common Abuses of Story Points (And What to Do Instead)

We’re not just naming agile buzzwords–we’re identifying real traps and showing clear practices to get out.

---

❌ 1. Comparing Story Points Between Teams

The trap:
Trying to normalize velocity across teams so management can compare performance.

Why it fails:
Story points are team‑relative heuristics. Comparing them across teams is like comparing “how spicy” a curry is between your grandma and a Michelin‑star chef.

It creates pressure to conform, explain numbers, and produce false precision where none exists.

🔁 Do instead:

• Keep story points internal to each team.
• Let teams share forecasts, not their raw estimates. Forecasts are what external stakeholders actually care about.
• Avoid normalization. If your stories are consistently small, drop estimates and simply count completed slices.

---

❌ 2. Measuring Velocity Per Person

The trap:
Breaking down team velocity to evaluate individual performance.

Why it fails:
This misrepresents how team-based work functions. It’s like tracking only goal scorers on a football team. A great team needs defenders, midfielders, a goalkeeper. If you only measure who scores, you end up with a team full of strikers–and no wins.

🔁 Do instead:

• Keep velocity at the team level. It’s a reflection of collective flow, not personal contribution.
• Build team habits around shared success: we win as a team, we lose as a team.
• Support individual growth through coaching and feedback–not performance metrics.

---

❌ 3. Ranking Individuals or Teams by Performance

The trap:
Using story points, ticket throughput, or other metrics to create internal rankings.

Why it fails:
This has been shown to decrease collaboration and productivity. People game the system, optimize for visibility, and hide problems instead of solving them. It breaks trust and encourages performance theater.

🔁 Do instead:

• Ditch rankings entirely. No leaderboards. No relative scoring.
• Focus on helping teams improve their flow and impact.
• Reward shared learning, experimentation, and outcomes–not artificial measures of “productivity.”

---

❌ 4. Assuming Velocity Means Value

The trap:
Treating a higher number of story points as proof of higher value delivered.

Why it fails:
Velocity measures output, not outcome. A team might finish 80 points of work that nobody needed. Another might deliver just two stories that change everything.

Just being busy doesn’t mean you’re being valuable. Read Goldratt–he wrote about this in the 1980s. Back then, high-performing companies already knew: keeping people 100 % busy kills flow. If you want to see the impact, watch Henrik Kniberg’s Resource Utilization Trap (YouTube).

🔁 Do instead:

• Ask: “What changed for the user?” “What value did we create?”
• Track real outcomes–customer feedback, adoption, behavioral change.
• Let velocity be a team-internal planning input, not a value metric.

---

❌ 5. Using Story Points to Predict the Future

The trap:
Using velocity and estimates to create detailed release forecasts.

Why it fails:
Estimates feel comforting. But most forecasts are just polite fiction. They’re not based on reality–they’re based on a desire to feel in control.

🔁 Do instead:

• Flip the approach: set your timebox or budget first. Not based on velocity, but on what you’re actually willing to invest.

  Example:

  • “We’ll explore this idea for six months.”
  • “We’ll invest €150 000 into this product opportunity.”
• That’s your constraint. Now prioritize the most valuable items and see how far you get.
• This is investment thinking, not estimation theater.

---

❌ 6. Using Story Points as a Substitute for Slicing

The trap:
Spending effort estimating big stories instead of learning to break them down better.

Why it fails:
If your stories are large and vague, estimates are just guesswork. If your stories are small, meaningful, and independent, estimates barely matter.

🔁 Do instead:

• Practice slicing by user value, not just technical layers.
• Aim for stories that take 1–3 days to complete.
• And yes–slicing is hard. But “impossible” often just means unpracticed. Every high-performing team I’ve worked with had to learn it.

---

❌ 7. Clinging to the Illusion of Control

The trap:
Using story points to feel in control–when you’re actually just insulating yourself from uncertainty.

Why it fails:
Many managers don’t want control–they want the feeling of control. Numbers provide that feeling. But real agility isn’t about reducing uncertainty. It’s about learning to respond to it.

🔁 Do instead:

• Teach the difference between complicated and complex systems. (The Stacey Matrix is a good place to start.)
• Move from command-and-control to sense-and-respond leadership.
• Replace rigid plans with fast feedback, trust, and adaptability.

---

🧭 TL;DR – How to Move Beyond Story Points

Stop	Do more	Aspire to
Comparing story points between teams	Share team-owned forecasts only	Use flow-based forecasts or throughput
Measuring velocity per person	Reflect on velocity at the team level	Focus on collaboration and shared success
Ranking individuals or teams	Encourage improvement, not competition	Build a learning, outcome-driven culture
Equating velocity with value	Ask what changed for the user	Track outcomes over output
Estimating to predict the future	Define time or budget up front	Prioritize value inside clear constraints
Estimating large stories	Slice stories into 1–3 day deliverables	Drop estimation and just count flow
Using metrics for control	Create feedback loops and inspect outcomes	Lead through trust and adaptability

---

Need Help Moving Beyond Story Points?

I’ve helped teams, leaders, and entire orgs make this shift–from estimation addiction to flow, slicing, and outcome-oriented agility.

If you want a thinking partner to help your team mature and move forward–let’s talk.

Also check out the Agile Games Collection to teach better slicing, collaboration, and flow using engaging, proven simulations. New games added monthly.

---

Read on the blog →