Introduction to Agile Metrics: The Pitfall of Story Points and Velocity
When it comes to Agile teams, many fall into the trap of focusing on story points and velocity as key metrics for success. While they may seem helpful, they often lead to inefficiency and distraction from what truly matters—delivering value to customers.
In my years of experience working with Agile teams, I’ve rarely seen a team that benefited from using these metrics. In fact, most teams end up prioritizing the wrong things—like trying to “win” at accumulating points instead of creating valuable products. Let’s dive deeper into why story points and velocity are misleading, and what you should be focusing on instead.
The Downside of Story Points: Measuring the Wrong Things
Why Do Teams Focus on Points?
Many teams fall into the trap of focusing on points for a variety of reasons:
Point manipulation: Teams may start adding unnecessary tasks to sprints just to rack up points.
Losing sight of value: The focus shifts from delivering customer value to “hitting the points target” for a sprint.
Inefficient sprint planning: More time is spent debating the point value of tasks rather than working on meaningful deliverables.
Unfortunately, these behaviors lead to a situation where the point becomes the point. Teams become more concerned with meeting point expectations than solving customer problems. This creates unnecessary tension and, ultimately, takes the team away from what really matters—delivering value.
💡 Pro tip: Instead of obsessing over points, focus on value-based discussions about what the team knows, doesn’t know, and what assumptions they need to test.
Focus on Throughput and Cycle Time
Rather than relying on story points and velocity, Agile teams should shift their focus to throughput and cycle time. These metrics provide a much clearer picture of how effectively the team is delivering real value to the customer. Here’s why:
Throughput: Measures how much work a team completes in a given period. It shows the actual value being delivered, rather than arbitrary points.
Cycle time: This tells you how long it takes for a task to move from start to finish, helping teams identify bottlenecks and improve flow.
Both of these metrics emphasize flow rather than estimation, ensuring the team remains focused on delivering tangible outcomes. Story points and velocity, on the other hand, often lead to a false sense of productivity and, as I’ve seen in many teams, very little benefit in the long run.
A Case Study: The Danger of Story Points in Contracts
I recently encountered a client who had one of the most extreme examples of Agile Banditry I’ve ever seen: story points written into the contract with a customer. Yes, you read that right. The team had to estimate story points upfront and provide those to the customer. Not only that, but the team would be penalized if they didn’t deliver within a specific range of points.
What Went Wrong?
Story points become the measure of success: Instead of focusing on the product’s quality or customer value, the team became obsessed with hitting point targets.
Incentivized dishonesty: The team felt compelled to inflate estimates to avoid penalties, leading to a lack of transparency.
Breach of contract risk: The contract had penalties for missing the point targets, which placed unnecessary stress on the team and made them focus on covering themselves rather than delivering quality work.
This is the opposite of what Agile is about. It promotes deception rather than collaboration. If you’re in a situation where story points are written into contracts, it’s time to ditch the story points. They don’t belong outside the team, and they certainly don’t belong in a contract!
🚨 Lesson learned: Never, under any circumstances, include story points in contracts. You’re setting your team up for failure, and you’re not promoting transparency or honest conversations.
Best Practices for Agile Teams: Ditch the Story Points
When Story Points Can Be Useful
Story points aren’t inherently evil. In the right context, they can be helpful, but only if used correctly:
Planning Poker: It’s a great tool for teams to collaboratively estimate and discuss unknowns. It encourages conversation around the complexity and risks involved in upcoming work.
Internal discussion tool: Story points can be useful for team-only conversations, allowing the team to reflect on their understanding of the work.
However, at the end of the planning session, delete the data. The story points have served their purpose, which was to facilitate conversation and understanding. Once that’s done, they no longer hold value.
⚠️ Caution: Story points should not be used as a performance measure by product owners or stakeholders. If your product owner is using velocity to monitor team performance, you’re on the path to Agile Banditry.
What Should Agile Teams Focus On?
If story points aren’t the answer, what is? Here’s a list of more objective metrics you should consider:
Throughput: How many user stories, features, or tasks are completed in a given time.
Cycle time: How long it takes to complete a task from start to finish.
Lead time: The total time from when a request is made until it’s delivered.
Customer satisfaction: The ultimate metric—how happy are your customers with what you’re delivering?
By focusing on these flow-based metrics, you’re setting your team up for success. You’re measuring the things that actually matter, rather than arbitrary numbers that don’t correlate with customer value.
🚀 Pro tip: Start tracking cycle time and throughput, and you’ll see an immediate shift in team focus towards value delivery rather than point accumulation.
Conclusion: Avoid Agile Banditry and Focus on What Matters
In summary, if your Agile team is spending more time worrying about story points and velocity than delivering value, you might be falling victim to Agile Banditry. Remember:
Story points are not the goal—delivering value is.
Focus on throughput and cycle time to measure real progress.
Never include story points in contracts—it leads to dishonesty and poor outcomes.
Use story points for team discussions only, then delete the data once the conversation has served its purpose.
