Story Points Are Useless — Here's What Actually Works

By Sahil Singh, Founder at Glue

I am going to say something that will get me uninvited from your next sprint planning ceremony: story points are useless. They have been useless for years. And yet, engineering teams around the world will spend this week debating whether a ticket is a 3 or a 5, as if the distinction carries real meaning.

I have watched dozens of teams burn hours on story point estimation, only to miss their sprint commitments anyway. According to the Standish Group's CHAOS report, 66% of software projects experience cost overruns. Not because teams cannot estimate. Because the estimation method itself is broken.

This post is not a rant. It is a diagnosis, with a prescription attached.

Story points were invented to abstract away time. The idea was that teams could estimate relative complexity without anchoring to hours or days. In theory, a team could say "this is twice as hard as that" and avoid the trap of false precision.

In practice, story points create a different trap: false consensus.

When your team assigns a story 5 points, what does that actually encode? Complexity? Uncertainty? Effort? Risk? The answer depends on who you ask, even within the same team. One engineer reads "5 points" as "a day of focused work." Another reads it as "I have never touched this module before and I am nervous."

Story points collapse multiple distinct dimensions into a single number. That number then gets aggregated into velocity charts, which get presented to stakeholders as if they measure progress. They do not. They measure the team's ability to complete work measured in the team's own made-up units.

There is a circular logic problem here that nobody talks about. Velocity measured in story points can only predict future work estimated in story points. It tells you nothing about actual outcomes: features shipped, bugs fixed, or user impact delivered.

The Planning Poker Problem

Planning poker makes the problem worse. It turns estimation into a social negotiation. Junior engineers anchor to senior engineers. Loud voices override quiet ones. The final number reflects group dynamics, not task complexity.

I have sat through planning sessions where a single ticket consumed 20 minutes of debate. Multiply that by 15 tickets per sprint, across 8 teams, and you have burned an entire engineering day on a ritual that produces unreliable numbers.

Here is what nobody is saying in the estimation discourse: the accuracy of any estimate depends entirely on how well you understand the code involved.

When an engineer says "I think this is a 3," they are implicitly claiming they understand the scope of change required. But in most codebases over 100K lines, that claim is a guess. Studies from the field show the mean effort overrun on software projects is approximately 30%, and the average overrun ratio is 1.8x the original estimate.

Why? Because codebases are opaque. Without tooling that shows you what a change actually touches, every estimate is a bet placed with incomplete information.

The real problem is not the estimation unit. It is the visibility gap. Consider what your team is missing when they estimate:

• File-level dependencies. Which files will this change actually affect?
• Ownership concentration. Who has the context to make this change safely?
• Coupling patterns. Will touching this module trigger changes in three others?
• Historical complexity. How often has this area caused bugs before?

Without answers to these questions, whether you use story points, t-shirt sizes, or ideal hours, your estimates are equally unreliable. The unit of measurement is not the problem. The absence of ground truth is.

If story points are useless, what should replace them? My answer might surprise you: stop estimating effort and start measuring impact.

File-level impact analysis gives your team something story points never could: an objective view of what a change will actually involve. Instead of asking "how hard do we think this will be?", you ask "what does the codebase tell us this will require?"

This approach works in three steps:

1. Map the change surface. Before estimating, identify every file, module, and service boundary the change will touch. This is not a guess. It is a query against your codebase's actual dependency graph.

2. Assess ownership and context. For each affected file, check who has context. If the change requires modifying files that only one engineer understands, that is a measurable risk, not a vibes-based story point bump.

3. Score based on observable signals. Churn rate, coupling density, test coverage gaps, and recent bug frequency in the affected area are all quantifiable. They produce a signal that is grounded in reality rather than consensus.

This is exactly the kind of analysis Glue was built to automate. Glue maps your codebase's file-level dependencies, ownership patterns, and complexity hotspots, then surfaces that information where your team makes planning decisions. Instead of debating points in a meeting, your team reviews actual data about what a change involves.

A Gitnux survey found that 65% of product and engineering leaders identify roadmapping and planning as their hardest challenge. File-level impact analysis does not eliminate uncertainty, but it replaces speculation with evidence.

The deeper issue with story points is what they optimize for. Velocity-based planning asks: "How many units of work can we complete per sprint?" Outcome-based planning asks: "What user or business outcomes will we deliver this quarter?"

These are fundamentally different questions, and velocity cannot answer the second one.

When you track velocity, you incentivize completing tickets, not delivering value. Teams learn to game the system. They inflate estimates so they can hit their velocity targets. They split tickets into smaller pieces to boost throughput numbers. The metric becomes the goal, and the actual goal disappears.

Outcome-based planning flips this. Instead of measuring how much you did, you measure what changed. Deployment frequency, change failure rate, cycle time, and customer impact become your signal.

The transition from velocity to outcomes requires one thing: better codebase visibility. You need to know what each change actually does, not just that it was completed. Glue's impact analysis provides this context, letting teams connect code changes to real-world outcomes instead of abstract point totals.

Making the Shift

If you want to move away from story points, do not try to replace them overnight. Start with one team and one sprint:

1. Drop planning poker. Replace it with a 10-minute review of the codebase areas each ticket will touch. Use file-level analysis to ground the conversation.
2. Track cycle time instead of velocity. How long does work take from start to done? This is an objective measurement, not a subjective estimate.
3. Measure outcomes, not output. At the end of each sprint, ask what shipped to users, not how many points were completed.
4. Use tooling to fill the visibility gap. Platforms like Glue can show you the actual complexity of planned work before your team commits to it.

The goal is not perfect estimation. It is better decision-making about what to build and how to build it. Story points do not help with that. Data about your codebase does.

---

Stop debating story points. Start understanding your code. Try Glue free and see what file-level impact analysis looks like in practice.

---

Why are story points useless?

Story points are useless because they collapse multiple dimensions of complexity, risk, and effort into a single abstract number. Different team members interpret story points differently, which means the resulting estimates lack consistency. They produce velocity metrics that are circular, measuring work completed in units the team invented, with no connection to actual business outcomes or user value.

What should you use instead of story points?

Instead of story points, use file-level impact analysis to understand the actual scope of changes before committing to them. Track cycle time as an objective measure of how long work takes. Focus on outcome-based planning that measures what shipped to users rather than how many abstract points were completed. Tools like Glue can automate the visibility layer that makes this approach work.

How do you estimate without story points?

You estimate without story points by grounding planning conversations in codebase data rather than gut feeling. Map the files and dependencies each ticket will touch. Assess who has the context to make changes safely. Review historical complexity signals like churn rate and bug frequency in the affected areas. This produces an evidence-based view of work scope that is more reliable than any point-based system.