Are Story Points Nonsense? The Truth About Agile Estimation

This article is part of the Developer Survival Kit.

Practical solutions to win back your focus time and deliver real results instead of just playing along in the "Agile Theater."

It's Monday, 10:00 AM. Planning Poker. You're staring at a ticket with the description "Refactoring Authentication Logic." You know that the code in this area hasn't been touched for three years and likely contains legacy code loops that could tie you up for days.

The Product Owner asks: "So, what are your estimates?"

You lay down an 8. Your colleague lays a 2. Someone else a 5. After ten minutes of discussion, you agree on the "middle ground": a 5. But in your head, you've already done the math: "5 points? In our team average, that's about 2.5 days... if nothing goes wrong."

Exactly here is where the bullshit starts.

If story points in your team are just a code word for time, then you are playing "Agile Theater." And you're not alone in your frustration: Even the man who (likely) invented them, Ron Jeffries, regrets it today.

Why Developers Hate Planning Poker

Planning Poker was actually intended as a tool to uncover knowledge gaps. If you lay an 8 and your colleague lays a 2, the number doesn't matter – what matters is the conversation about why you think so differently.

But in reality, Planning Poker is often a mix of several ingredients. There's the PO who might be tempted to push the estimate down ("Can't this be done faster?"). Then there's peer pressure. You agree on the average just to finally get back to your desk. And then there's the pressure to justify. You'd rather estimate defensively ("Better an 8 than a 5") to have a buffer for unforeseen meetings.

The result is a number that has little to do with reality but looks like it's carved in stone in the Jira backlog.

The Misunderstanding: Complexity vs. Time

Ron Jeffries, one of the fathers of XP (Extreme Programming), says quite openly today:

I like to say that I may have invented story points, and if I did, I’m sorry now.

Originally, points were intended to decouple estimates from time. The idea was to talk about complexity, risk, and effort. Why? Because our brains are terrible at estimating time ("How many hours will this take?") but quite good at comparing things ("Is this feature larger or smaller than the last one?").

But that's where the problem arises. As soon as someone on your team says "1 point corresponds to 4 hours for us," you've killed the concept. And I can say from my practice that this always happens.

Time is a constant. Complexity is not. If you write a ticket in a new language, the complexity is high, even if the code is only 10 lines long. If you estimate it in time, you are lying to yourself.

Velocity is not a Performance Indicator

The biggest crime against the agile idea is using velocity (the sum of points per sprint) as a performance metric.

When management asks: "Why does Team A have a velocity of 40 and Team B only 20?", then this happens: Point Inflation. Team B will simply start estimating everything higher in the next planning. A 3-point ticket becomes a 5, a 5 becomes an 8. On paper, the team is suddenly "more productive," but nothing has changed in the code.

Ron Jeffries warns that this pressure leads teams to skimp on quality. You skip tests or refactoring just to "whip the points through the pipeline." The result? Technical debt that catches up with you two sprints later. But there are alternatives to story points!

Alternative 1: T-Shirt Sizes for the Big Picture

If you need estimates to give the business a rough direction, use T-Shirt Sizes (S, M, L, XL).

• S: We do this in passing.
• M: A normal feature.
• L: Large, we probably need to slice it.
• XL: An entire epic that we don't understand yet.

The advantage: Nobody gets the idea of converting an "L T-shirt" into hours. It remains an abstract classification of volume, which is completely sufficient for quarterly planning.

Alternative 2: Flow Metrics & Monte Carlo (Data instead of Guessing)

There is a mathematically sounder solution: Flow Metrics. Instead of looking into a crystal ball, we look into the past.

Throughput: How many tickets do we finish per week? (Regardless of how big they are).

Cycle Time: How long does it take on average from the start of a story to deployment?

If you've had a larger number of tickets in the past, you can also use a Monte Carlo Simulation. This calculates the probability of when a project will be finished based on your real data.

In detail: A Monte Carlo simulation runs, for example, 10,000 simulations of your sprint or project. It doesn't roll dice randomly but uses the distribution of your real historical throughput.

• Run 1: The simulation assumes you are as fast as in your best week (e.g., 12 tickets).
• Run 2: It assumes you have a week like during the summer slump (e.g., 2 tickets).
• Runs 3 to 10,000: It combines these probabilities again and again.

The result: Not a single-point lie, but a histogram.

In the end, you don't get a date ("We'll be finished on October 12th"), but a probability distribution (percentiles):

• 50% probability: October 10th (Very optimistic, a coin-flip chance).
• 85% probability: October 24th (The "commitment" level you can plan with).
• 95% probability: November 5th (Certainty for critical deadlines).

Instead of saying "We'll do this in 3 weeks," you say: "With an 85% probability, we'll be finished in 22 days." That's no longer guessing; that's science. And it takes the emotional pressure out of Planning Poker.

I have recorded a podcast episode about flow measurement in teams (German audio) – in case you want to listen in.

I also built a Flow Physics landing page that explains the principles of flow to you.

How to Reassure Management Without Estimates

Management usually only wants estimates for one reason: fear of uncertainty. They want a date to have a feeling of control. They need to plan and, if in doubt, justify themselves to others.

To meet them halfway, I have the following tips for you.

Slice it down. Cut tickets so small that every ticket can be completed in 1–2 days. Then you don't need points anymore; you only need to count tickets (Throughput).

Transparency about variance. Show management that estimates at the beginning of a project are always wrong.

Promise flow, not points. Explain that a stable cycle time is more valuable than a high velocity. A stable process allows for predictions; estimation poker only allows for wishful thinking.

Conclusion: Estimate Less, Deliver More

Story points were intended as a shield for developers to avoid being nailed down to hours. Today they are often used as a whip. If your team suffers from estimation compulsion, try the No-Estimates approach: slice the stories as small as possible (maximum 1 day of work) and simply track how many you manage per sprint. This saves hours of senseless discussions in planning and provides management with more accurate data. Because at the end of the day, it's not how many points are in Jira that counts, but that working code is in production creating value.

Anyone under pressure to estimate tends to skimp on quality. The result is technical debt that costs you twice as much time in the next sprint.

What's Next?
Anyone under pressure to estimate tends to skimp on quality. The result is technical debt that costs you twice as much time in the next sprint.

📉 Next step: Selling Technical Debt Economically
🏠 Back to overview: The Agile Survival Kit for Developers

Did this guide help you?
Share it with your team or discuss it with me on Mastodon. Real feedback helps me make this content even better for devs!