Story Point Abuse: Stop It!


The Agile Compass

Matthias Orgler

Story Point Abuse: Stop It!

Are you ready to put an end to the chaos of story point abuse that’s wreaking havoc on your agile team?


Hello Reader,

let's talk story point estimations today – and it's common abuses.

But before we start, here are some related articles you might have missed:


Story Point Abuse: Stop It!

Alright, we need to talk about something that’s been going on far too long in the agile world. You know what I’m talking about: Story Point Abuse. We’ve all seen it, we’ve all felt the pain from it, and it’s time we put an end to it. So let’s get real for a second and break down the most common ways story points are misused—and how you, yes you, can stop the madness.

1. Equating Story Points with Time

Ah, this old chestnut. Let me guess, someone on your team (or worse, some manager lurking outside the team) is insisting that 5 story points should take exactly 5 hours—or maybe 5 days? Sound familiar? Here’s the deal: story points are not hours, days, or any other unit of time! They are about complexity, risk, and effort. When you start treating them like a stopwatch, you’re ignoring the very reason we use them—to account for things beyond just time. Maybe something is tricky or involves unknowns, or requires different skill sets. All of that gets thrown out the window when you reduce it to “this should take x amount of time.”

Trust me, I’ve been there. I’ve seen teams burn out because they’re expected to magically align their work with a time-based point system. And guess what happens? They stop seeing story points as useful. They lose morale. Productivity takes a hit. Don’t let that happen to your team!

2. Involving Only Part of the Team

Story points aren’t something for just a couple of people to figure out while everyone else quietly nods in the corner. No way! Estimations need to be a team sport. When just one or two folks are doing the heavy lifting on estimates, you miss out on diverse perspectives. There’s a reason why teams are cross-functional, right? You want input from the developers, the testers, the designers, the product folks—everyone! Why? Because each role brings unique insights into the work.

I’ll tell you this, one time I was on a team where only the lead developer would estimate. And sure, they were good, but they weren’t omniscient. We’d frequently miss hidden complexities in testing or unforeseen product challenges. When the whole team jumped in, our estimates became far more accurate. Teamwork, baby!

3. Settling for Average Estimates

This one’s sneaky because it feels like a compromise, but it’s really just papering over a problem. You’ve got different estimates on a story, so what do you do? Average them and move on, right? Wrong!

Averaging estimates just glosses over the disagreements. If one person thinks a story is a 3 and another thinks it’s a 13, that’s a conversation waiting to happen. Don’t settle! Find out why those estimates are so different. Is someone seeing a risk others aren’t? Is there a misunderstanding about the requirements? This is where the magic happens—where your team learns, grows, and becomes more accurate. Don’t skip that!

4. Using Exact Numbers Instead of Ranges

This is for all the perfectionists out there. You might love the idea of a precise estimate: “This is exactly 5 story points.” But here’s the thing—software development is not an exact science. It’s full of uncertainty, complexity, and change. Story points should reflect that. You’re better off thinking of them as ranges or levels of effort rather than pinning down a number like it’s some immutable truth handed down from the agile gods.

But here’s the good news! Even though we start with these abstract and fuzzy story points, we will eventually get back to something more specific: dates. Yes, you read that right. Through the consistent use of velocity—how many story points your team is able to complete in a sprint—you’ll start to develop a rhythm. This rhythm allows you to project how long future work might take. And while we’re still talking about ranges (because, let’s be honest, uncertainty never really goes away), those ranges get tighter and more reliable over time.

Want to learn more about how velocity helps turn those fuzzy story points into date ranges you can plan around? I’ve got you covered—check out my articles on velocity and mastering deadlines with agile methods!

5. Gaming the System

Oh, this one makes my blood boil. Gaming the system—manipulating story points to fit some preconceived target. It’s like trying to squeeze into a pair of jeans you’ve outgrown. Sure, you might get them on, but nobody’s comfortable, and eventually, something’s going to rip.

I’ve seen teams inflate their estimates to make their velocity look better. I’ve also seen the opposite—underestimating to hit some arbitrary deadline. Both are disastrous. Not only does this skew your data, but it also completely undermines the trust in your process. And once that trust is gone, good luck getting it back. Be honest with your estimates! Don’t use them as a tool to manipulate the system. It’s about delivering value, not fudging numbers.

So, What’s the Fix?

It’s simple—respect the process! Story points are there to help your team, not hurt them. Use them as a tool for measuring complexity, effort, and risk. Get the whole team involved, embrace discussion, and remember that precision isn’t the goal—understanding is. And most importantly, keep it real. Don’t let numbers distract you from what truly matters: delivering value to your users.

Now, go forth and stop story point abuse in its tracks. Your team will thank you. And who knows, maybe one day, story points will regain their good name. But it all starts with you!

Next: Check out my articles on velocity and mastering deadlines with agile methods.

Thank you for reading The Agile Compass. I'm Matthias, here to help you help those around you become agile.


To get more, consider upgrading to a paid subscription. You’ll join our premium Discord community and get access to all past articles.

The Agile Compass is a newsletter for agile practitioners. You're receiving this email, because you subscribed on matthiasorgler.com. To unsubscribe or change your preferences, use the links below or just write me by replying to this email.

Kohlbrandstr. 20, Frankfurt, He 60385
Unsubscribe · Preferences

The Agile Compass

How to create high-performing teams, innovative products and lead thriving businesses? The Agile Compass shares hands-on knowledge from 20+ years of experience in industries worldwide. Matthias is a Silicon Valley veteran and has been awarded the Agile Thought Leader award in 2022. His unique approach focuses on the human side of creating thriving businesses.

Read more from The Agile Compass

The Agile Compass Matthias Orgler Hello Reader, today I want to talk about Scrum. But before we dive in, here are some articles you might have missed in the past weeks: How to motivate people The Boss Worker Game (I'm actually creating a collection of agile games; if you're interested, sign up here) Why your Sprint Retrospectives fail Is Scrum Anti-Agile Because It Can’t Be Changed? No! In fact, the opposite is true—Scrum is a very agile framework, but there are a lot of common...

The Agile Compass Matthias Orgler Hello Reader, is your Product Owner detached from the team? Writing lots of user stories? Fulfilling a DoR? We'll talk about why that's not helpful in today's article.Before we start: Here are a few past articles about Product Owners you might have missed: How long is your backlog? 90% done user stories Sprint Plannings without a Sprint Goal User stories are not about writing Finalizing the plan How to demo the backend Don't ignore the preconditions of Scrum...

The Agile Compass Matthias Orgler Nice guys finish last – or do they? Discover how kindness and empathetic leadership led to the rapid construction of the Empire State Building—and why putting people first can be the key to winning at work. Hello Reader, today we will talk about people again. Because leadership and agility are more about people than about processes, organizations or frameworks.Here are a few other articles that also focus on the human aspect: How to overcome resistance to...