Story points are quietly destroying engineering teams. Not because the concept is inherently broken, but because of what happens when a proxy metric gets treated as a primary one — and what that treatment does to the people being measured by it.
I've spent a decade inside large, high-stakes engineering organisations. I've seen story points used well exactly twice. I've seen them used to produce dysfunction hundreds of times. The dysfunction is always the same: the metric colonises the goal. Teams stop optimising for outcomes. They start optimising for points.
What Story Points Were Actually Invented For
Story points were never designed to measure productivity. They were designed to help teams estimate relative complexity so that sprint planning could be more realistic than raw time estimates. That is a legitimate and limited use case.
The person who coined the term — Ron Jeffries, one of the original XP proponents — has publicly stated that he regrets the invention. He's watched the abstraction become a management instrument it was never intended to be. The tool that was supposed to help developers say "this task is bigger than that one" became a KPI on a dashboard watched by people who have never estimated a piece of software in their lives.
When a metric moves from a planning aid to a performance signal, its meaning changes. Engineers are not naive. They respond to the incentive. The response is rational, predictable, and expensive.
The Ratchet Effect Nobody Talks About
Here is the mechanism that makes velocity particularly corrosive. In the first sprint, the team estimates honestly. In the second sprint, the Scrum Master or engineering manager reports velocity to leadership. Leadership asks: "How do we increase this number?" The team inflates estimates — consciously or unconsciously — to show improvement. By sprint six, story points have no relationship to complexity. They are a currency that has been debased.
I call this the ratchet effect. Velocity only moves in one direction because anything that looks like a decline triggers a conversation nobody wants to have. The metric becomes a floor, and the floor gets systematically raised through drift in estimation norms, scope narrowing of individual stories, and — most damagingly — splitting genuinely complex work into smaller stories that each score well independently while the complexity of the integration disappears from view entirely.
When velocity becomes a target
Goodhart's Law is precise here: when a measure becomes a target, it ceases to be a good measure. Story point velocity is particularly susceptible because it is abstract enough that gaming it feels justified. Engineers don't think of themselves as gaming the system. They think of themselves as responding reasonably to an unreasonable measurement approach. They are right.
What the Metric Hides
The deeper problem with velocity is not that it can be gamed — it's what it makes invisible.
Technical debt accumulation. A team that is moving fast on velocity but accumulating technical debt looks identical, on a sprint report, to a team that is moving fast with clean code. The difference shows up 6 to 18 months later as a velocity collapse that seems sudden but was entirely predictable.
Quality degradation. Story points measure output, not outcomes and not quality. A team that ships 80 points of poorly tested, insufficiently reviewed code is rewarded identically to a team that ships 80 points of production-grade work. The difference becomes a customer incident, or a security breach, or a performance regression that costs six weeks to diagnose.
Architectural erosion. The pressure to maintain velocity discourages the work that doesn't produce story points: refactoring, documentation, test coverage, architectural review, incident post-mortems with action items. These are exactly the activities that determine whether a codebase remains navigable at 30 engineers. Velocity pressure makes them feel like luxuries.
Engineer wellbeing. When engineers are measured by story point output, the implicit message is that they are story-point generators. The engineers who understand the craft most deeply often react the worst to this framing. They know that quality work sometimes takes longer. They experience velocity pressure as a signal that the organisation does not understand — or does not value — what they actually do. The people most likely to leave are the ones most likely to know why they should.
What to Track Instead
The alternative is not to stop measuring. It's to measure things that have a direct relationship to the outcomes the business actually cares about. The DORA research gives us the framework.
| Metric | What It Measures | Why It Matters |
|---|---|---|
| Deployment frequency | How often code reaches production | Throughput without the abstraction; harder to game because it requires actual deployments |
| Lead time from commit to production | End-to-end delivery speed | Captures bottlenecks in review, testing, and deployment that velocity hides |
| Change failure rate | Percentage of deployments that cause an incident | Quality signal at the system level; not gameable without degrading customer experience |
| Mean time to restore (MTTR) | How quickly production incidents are resolved | Operational maturity; reflects investment in observability and on-call discipline |
| Cycle time per work item | Time from "in progress" to "done" | More honest throughput measure than story points; reveals queue depth problems |
These are not perfect metrics. No metric is. But they share a critical property that story points lack: they are difficult to improve without actually improving the thing they measure. You cannot increase deployment frequency by inflating your estimates. You cannot reduce lead time by adding points to a story. You cannot improve change failure rate by splitting tickets.
The DORA Elite benchmark gives you a concrete target: deployment frequency measured in multiple deploys per day, lead time under one hour, change failure rate below 5%, MTTR under one hour. Most enterprise engineering teams I've worked with are nowhere near these numbers. That gap is not a performance problem. It's a process and infrastructure problem — which is exactly the kind of problem that's solvable, once you're measuring the right things.
How to Make the Transition Without Chaos
Abandoning story points does not mean abandoning planning. Planning still requires some form of sizing. The question is what you do with the sizing once you have it.
Stop including story points in any report that goes above the team level. Estimation can remain a planning tool. The moment it becomes a reported metric, it becomes a target, and the ratchet begins. If leadership asks "what's your velocity?", the honest answer is "we measure deployment frequency and lead time now — here's what those look like."
You cannot report on deployment frequency or lead time without instrumenting your pipeline. This is usually a one-sprint investment: connect your source control, CI/CD, and incident management tools to a single dashboard. Tools like LinearB, Swarmia, or a simple custom query against your GitHub/GitLab data will surface these metrics without requiring any behavioural change from engineers.
Run the new metrics for four to six weeks before setting targets. You need a baseline to understand what "good" looks like in your context. An org that deploys twice a week is not the same as an org that deploys once a month — the baseline determines the meaningful improvement trajectory.
If teams need to communicate relative scope to product or leadership, T-shirt sizing (S/M/L/XL) is more honest than story points. It communicates what it claims to communicate — rough relative size — without creating the illusion of precision that makes story points so dangerous.
Enforce minimum test coverage, mandatory code review, and automated security scanning at the pipeline level. These should not be optional under delivery pressure. If they can be bypassed when velocity is low, they will be bypassed whenever velocity is low — which is precisely when the risk of cutting corners is highest.
The Conversation With Leadership
The hardest part of this transition is not technical. It's political. Leadership has a dashboard with a number that goes up and down. You are proposing to replace that number with four numbers that they don't understand yet. This feels like losing information, not gaining it.
The reframe that works: "Story point velocity tells you how many things we started and finished. Deployment frequency tells you how often customers get value. Lead time tells you how long it takes from idea to production. Change failure rate tells you what percentage of our deployments make things worse. These numbers tell you what the business is getting from engineering. The other number told you how busy we looked."
Most technical leaders I've worked with have experienced the moment when a team shows high velocity for three sprints and then delivers something that breaks in production immediately. That experience is the proof point. Velocity looked great right up until it was clearly irrelevant.
The one metric question worth asking
If your current engineering metrics were perfect, what business outcome would you be able to predict from them? If the answer is "none," you're measuring the wrong things. The right metrics have a visible line of connection to revenue, customer satisfaction, or risk — even if the line is indirect. Story points have no such line. DORA metrics do.
What the Best Teams Actually Do
The highest-scoring engineering organisations I've assessed — across insurance, energy, industrial, and SaaS contexts — share a consistent pattern. They track delivery metrics (DORA or DORA-equivalent), they have a defined change failure rate budget, and they treat that budget as non-negotiable: when the budget is being consumed, the team stops shipping new features and fixes the quality problem first.
They do not track story point velocity. In some cases they track cycle time per item as a planning tool. The number is never shown to anyone outside the engineering team. It is never used in a performance review. It is never reported upward. It is a team-internal signal, treated as such.
The other thing these teams share: engineers describe their work in terms of customer outcomes, not ticket completion. That framing is not accidental. It reflects a measurement environment that connects engineering work to business results — which is exactly what story points cannot do, no matter how precisely they are estimated.
If you're making the case internally for better engineering metrics — or trying to understand why your team's delivery feels disconnected from the numbers on the sprint report — let's talk. I help technical leaders design measurement frameworks that actually reflect engineering performance. Book a 30-minute discovery call and let's look at what your current metrics are actually incentivising.