There is a long-running argument in Engineering communities that goes roughly like this: story points are fake, velocity is gameable, estimation is overhead, and the whole apparatus of sprint planning exists to make managers feel in control of work they don't understand. Just give us Kanban and let us do the work.
I've never agreed with it.
Sometimes it is people rebelling against structure for the sake of rebelling. Sometimes it is a reasonable response to watching companies weaponize velocity against their own teams. If that's your experience with it, you understand why engineers want nothing to do with the measurement.
But throwing out the measurement is the wrong response to the measurement being misused.
The original intent of story points was to solve a specific set of problems that time-based estimation couldn't solve.
Humans are poor at estimating time. We anchor to best-case scenarios, underweight complexity, and ignore the invisible work that sits between "I know how to do this" and "this is done." Holding engineers accountable to time estimates on work that is inherently uncertain punishes accuracy and rewards sandbagging. The engineer who says "three days" and takes four gets dinged. The engineer who says "two weeks" and takes ten days looks like a hero. The incentives point in exactly the wrong direction.
Story points were designed to break that loop. Relative complexity instead of absolute time. A three is harder than a two, simpler than a five, without committing to how many hours any of them take. Individual variation gets absorbed into the team's velocity rather than exposed as a personal failure. A task that takes a senior engineer two hours and a junior engineer two days is still a two. The team's historical throughput tells you how many twos they can get done in a sprint.
It was also supposed to make scope negotiation honest. You can't tell a team to do a three in two hours instead of four. You can try, but the number stops meaning anything the moment it gets treated as a time commitment, which is exactly the point. Instead, you talk in terms of quality, debt, and complexity.
Like most good ideas, it got corrupted. Most organizations adopted the vocabulary and dismissed the philosophy. Story points became a proxy for time anyway, because we all reason about effort in time naturally and nobody explained why that mattered. Top-down leaders started imposing targets in points instead of hours, and all the original dysfunctions returned in new clothes. Engineers started padding estimates to protect themselves. Velocity targets replaced time targets. The measurement that was supposed to create safety became another thing to game.
That history is why the anti-estimation crowd exists. They're not wrong about what happened. They're wrong about what to do next.
I ended up in a conversation recently about remote work. Someone was struggling to get people back into the office in Austin. I mentioned that I used to lean toward in-person, but COVID changed my view.
When my teams were forced home, their velocity went up 30 to 35 percent. There was an obvious inflection point in the graph right at the transition. I acknowledged there were confounding factors. People were anxious. Nowhere to go. Familiar work as an anchor while everything else was destabilizing. You can't fully isolate the variable.
But the lift was undeniable. And it was visible because I was tracking it.
Somebody asked how I knew that. I told them: I tracked my team's velocity. They asked how I tracked value.
My answer was: I don't. That's not Engineering's job.
I could feel the flinch. So let me explain what I actually mean.
Engineering's job is to build the things the company has determined are most important to build. Engineers have real influence on that determination and should be in those conversations, because only they know the true cost of building a thing. But Engineering is not the function making the call on what gets built. Product owns the roadmap. The business owns the value hypothesis. If you're committing to building something, someone should have already estimated what it's worth and how you'll know if it worked.
Where organizations fail is skipping that step entirely, then asking Engineering why the thing they built didn't move the needle.
That said, Engineering isn't off the hook entirely. In the organizations where this has worked well for me, Engineering is expected to instrument whatever we ship. Real-time signals. Time series data out of the application. Is the thing being used the way we expected? As frequently? Producing the outcomes we said it would?
I want my team to know whether something worked before the rest of the business knows. Lagged reporting means most organizations are at best a week and hopefully not worse than a quarter behind on everything. We don't have to be.
And when the data shows the thing isn't working, Engineering should be advocating for iteration or removal. Not waiting to be told. An underperforming feature nobody kills is dead weight. Engineers carry it around in their heads and have to work around it in the codebase. The associated tests carry costs in both compute and real-time delays to deployment. Carrying the data impacts the database. If it involves third-party vendors, there are monthly usage fees. These are real costs that impact the business.
Here's the question that brings all of this back to estimation: how can an organization reason about ROI at all if it doesn't know what things cost to build?
Throughput data answers the cost side of that equation. Cost per sprint is not complicated. Take what you're spending on an Engineering team and divide by the sprint cadence. That's what two weeks of that team's capacity costs you in real dollars. Scope a chunk of work into that container and you have a cost estimate for the project. Compare it to the value hypothesis. If something costs $20,000 to build and the expected return is $5,000, that's a real decision. You can make it with data instead of intuition and politics.
The indirect cases are harder but not impossible. Quality-of-life work, technical debt paydown, reliability improvements: none of these generate direct revenue. The ROI calculation requires a different kind of reasoning.
You estimate what the work costs. You estimate what it saves in support burden, unplanned Engineering expenditure, and regained capacity. Then you make the case. I've had that conversation in real rooms with real numbers. "We should pay down this debt" is easy to defer. "We're spending $X a month on incidents caused by this, we can fix it for $Y and reclaim Z capacity" is a different conversation. One has a payback period. The other is just a feeling.
None of that reasoning is available if you don't know how much your team can get done.
There's a related problem that doesn't get talked about enough: investment thesis.
Suppose you want to protect 10% of Engineering capacity for quality-of-life work and hold a 15% buffer for mitigation. That's a real strategic position. But 10% of what? If you don't know your baseline throughput, that's not an allocation, it's an aspiration. The number has no anchor.
Product owns prioritization. But Engineering has to show up to that conversation with data or the investment thesis never gets concrete. Product can't allocate 15% to mitigation if Engineering can't tell them what 15% looks like in practice. The data is Engineering's contribution to a conversation Product is nominally running.
Velocity is not your leading metric. I've written about that at length, and I'll stand by it. Predictability is the leading metric. Velocity is what you watch when you want to know if something just changed.
Think of it as a canary. A canary doesn't tell you what's wrong. It tells you something is.
Incidents go up. That's alarming on its own. But watch the velocity. Incidents force context switches. Context switches destroy focus. Focus is what produces throughput. So the incident cost isn't just the incident ticket and the cleanup. It's an invisible tax on everything else that sprint. That number almost never appears in a post-incident review.
You make a change to the CI pipeline expecting better performance. Velocity goes the wrong direction. Now you have a real signal that something in the change didn't work the way you thought, before it becomes a habit and before anyone has decided it's fine.
You hire someone new. Velocity should go up, eventually. What if it doesn't? That's a question worth asking early. It might be onboarding friction. It might be knowledge transfer debt. It might be that your senior engineers are now spending half their capacity getting someone up to speed and nobody has accounted for that. None of those things are the new hire's fault. All of them are visible in the data before they become a conversation anyone is ready to have.
The canary doesn't optimize anything. It just tells you to look.
And here's where the canary connects back to ROI: because you can see the velocity drag in points, you can quantify what a problem is actually costing you.
Say you have an unstable artifact. It's causing incidents. Each incident pulls the team sideways. You can see it in the sprint data. The artifact is bleeding capacity, sprint over sprint, at a measurable rate.
Now the conversation with the business becomes: we want to invest 20 points this sprint to stabilize this thing. Based on the capacity it's currently consuming, we expect to recoup that investment within three sprints of recovered throughput. Everything after that is pure capacity we get to spend on something that matters.
That's a capital allocation argument. It lands differently than "we need to fix this thing."
You can only make that argument if you were tracking throughput in the first place. The engineers who wanted to skip the overhead are the ones whose leaders can't have that conversation. Which means the instability keeps burning capacity, sprint after sprint, with no legible business case for fixing it.
The overhead objection is real. Points are an abstraction. Estimation takes time. The process can be gamed. All true. But the engineers who most want to skip it are often the ones who end up least protected. Their leader has no data to push back with when the business adds three more weeks of scope to a two-week sprint. No visibility into whether that new ticket is an hour or a month.
The dysfunction that made engineers hate story points was never in the measurement. It was in what organizations did with it. Use it to set targets, and you get sandbagging and gaming and all the original problems dressed up in new vocabulary.
Use it the way it was designed, as a signal rather than a verdict, and you get something worth having. A leader who can see what's happening and reason about cost. Who can protect capacity, push back on scope, and make the business case for the work that doesn't have an obvious sponsor.
That's not a forecasting model. It's not a performance review. It's the data that lets you take care of your team.
I write about engineering leadership and team health in the Engineering Health newsletter on LinkedIn. Search "Engineering Health" to find it.
Top comments (0)