Over seven years of running Story Points workshops, I’ve seen the same pattern: teams learn the technique, apply it for a few sprints, then gradually drift back to old habits. At my current scale — 47 teams, around 400 people in IT — 60% use Story Points, 40% don’t. What’s interesting: those 60% who do use them do it completely differently.

Even 3 months after the training, only 20-30% use Story Points correctly (as intended). The problem isn’t the tool itself, but how we use it and what we expect from it.

1. Without a Scrum Master, Story Points Quickly Degrade

The Problem: Story Points are a facilitation tool for discussing complexity, risks, and uncertainty. Without constant coaching, teams start using them mechanically — just to “slap a number on it” and move on.

What Happens: Teams go through training, estimate tasks “correctly” for a few sprints, discussing details and identifying risks. Then the process simplifies: people silently assign numbers without asking questions or aligning understanding.

What to Do: If you don’t have resources for dedicated Scrum Masters, consider simpler approaches. Flow metrics require less coaching and provide objective data automatically.

2. Story Points Don’t Reflect Real Work Flow

The Problem: Even perfectly estimated tasks can get stuck in the system. Backlog items “age” regardless of their Story Points. A 3-point task might hang in Code Review for a week, while an 8-point task flows through the entire cycle in a day.

What Happens: Story Points estimate task “complexity/risk/effort” but don’t show how work moves through the system. They don’t account for bottlenecks, dependencies, priority changes, and other systemic factors.

What to Do: Supplement Story Points with flow metrics:

• Cycle Time — time from start to completion
• Throughput — number of completed tasks per period
• Lead Time — time from request to delivery
• Aging — how long tasks sit in the system

All of the dots are 5-Story Point estimated items. Stuck in respective statuses for different reasons.

3. Story Points Create an Illusion of Precision

The Problem: Teams use Story Points for precise short-term forecasts, though they weren’t designed for that. Research shows: if you assign “1” to every task instead of Story Points and count throughput, forecasts are often equally accurate.

What Happens: An average velocity of 20 Story Points doesn’t ensure exactly 20 will be done in the next sprint. It’s similar to Mike Cohn’s basketball example: averaging 98 points per game doesn’t promise 98 in the next game.

What to Do:

• For long-term planning: use average velocity understanding its variability
• For precise forecasts: statistical methods based on historical data (Monte Carlo simulations)
• For business answers: honest ranges with probabilities, not exact dates

Example from one of the teams I worked with. Different colors = different estimations in SP. 1 (red) ,2 (yellow), 3 (green), 5 (blue) ,8 (violet)

4. Story Points Don’t Scale Between Teams

The Problem: In large organizations, each team “calibrates” Story Points differently. One considers 5 SP medium complexity, another considers it high. This makes cross-team performance comparison or product-level planning impossible.

It’s my perspective from the past jobs when I work at scale: you need to assess the team’s predictability. You also need to evaluate their accuracy in planning, and fast.

What Happens: Without unified standards and constant alignment, Story Points become a “Tower of Babel” — each team speaks its own estimation language.

What to Do: For cross-team planning, use objective metrics: Throughput, Cycle Time, Lead Time. They don’t depend on subjective interpretation and provide comparable data. And it would be good to see Planning Accuracy (how has been Completed/Committed rate over the past 6 periods).

5. Story Points Don’t Help Improve the Process

The Problem: Story Points don’t show where work gets stuck. They don’t provide insights for identifying bottlenecks and improving processes. A team can perfectly estimate all tasks while having serious flow problems.

What Happens: Focus on precise estimation distracts from analyzing how work moves through the system. Velocity stays stable, but customers don’t get value on time.

What to Do: Analyze work flow using cycle time scatterplots, and aging metrics. This reveals real problems and improvement opportunities.

Practical Approach: Separating Tools and Goals

The problem isn’t Story Points themselves, but mixing tools and purposes.

Story Points — for internal team planning:

• Discussing complexity and risks within the team
• Aligning understanding of tasks
• Revealing hidden assumptions and dependencies

Flow Metrics — for forecasting and improvement:

• Reliable business forecasts
• Bottleneck and process problem analysis
• Objective data for decision-making

Evidence-based approach: As Vasco Duarte states, try both methods for several sprints, compare forecast accuracy. Let data show what works better in your context.

Conclusion

Story Points are a valuable tool for teams. They need to be used properly for effectiveness. I still do workshops on them. They are useful and effective for discussion and internal team planning. If your goal is reliable forecasting, flow metrics often deliver better results. They also improve process and scaling with less effort. We’ll dig into that in some other post.

Be honest with business. Instead of false precision, provide realistic ranges with probabilities based on actual data, not subjective estimates.

Want to compare forecasts based on Story Points vs. flow metrics? Try Predictable.Team — a tool for analyzing flow metrics from your data.