Better Metrics for Software Teams beyond story points

The content here is under the Attribution 4.0 International (CC BY 4.0) license

In this space, I want to explore some alternative metrics that can provide a more accurate and meaningful way to measure the performance of software teams. Along the journey, I will try to explain what I mean by that and provide examples of how these metrics can be used in practice. But I will give you a hint: story points might have been the most used metric because they are easy to track, but not necessarily impactful. Ron Jeffries blogged about it (Jeffries, 2019) and said “Well, if I did invent story points, I’m probably a little sorry now, but not very sorry. I do think that they are frequently misused and that we can avoid many pitfalls by not using story estimates at all. If they’re not providing great value to your team or company, I’d advise dropping them on the grounds that they are waste. If, on the other hand, you just love them, well, carry on!”.

Why this matters and why now?

Every now and then, I get the chance to join a new team, and it typically takes no more than a couple of weeks to see the team struggling with the same issues: lack of focus, lack of clear goals, lack of trust, lack of ownership. However, there is one single thing that is always present, no matter what: the need to use Scrum.

Before diving into the metrics

It might be worth mentioning that the approach taken here is based on a healthy team model, where the focus is on the well-being and productivity of the team as a whole, rather than just individual performance.

Dev and Ops

The advent of DevOps has blurred the lines between development and operations, making it essential for teams to work together seamlessly. Metrics that capture the collaboration and efficiency of both development and operations can provide a more holistic view of team performance.

Going a step further

Change Frequency: How often a file or function gets tweaked. A proxy for “interest rate”—the hotter the interest, the hotter the code’s smell. tonytvo.github.io understandlegacycode.com

Simple Complexity Indicators: Traditional static metrics like cyclomatic complexity aren’t the only game. Lines of Code (LOC) and indentation depth offer language-agnostic signals. understandlegacycode.com

Hotspots: The critical combo—files or functions with high change frequency AND high complexity. These are your code’s real estate that demands the most maintenance attention. tonytvo.github.io understandlegacycode.com

Complexity Trends Over Time: Trace the rise or fall of complexity for these hotspots. Maybe code is growing wild—or maybe refactoring has tamed it. tonytvo.github.io understandlegacycode.com

X-Ray Analysis: Drill deeper from file-level hotspots into suspect functions. Here, you calculate per-function change frequency and complexity across versions, combining them into a priority score. understandlegacycode.com

Code Age Awareness: How old is the code? Older modules usually harbor fewer bugs—some researchers say about one-third fewer faults if a module is a year older. kula.blog

An approach for teams

A Data-Driven Approach to High-Performing Teams

Agile software development has become a dominant practice, but many teams struggle to consistently deliver high-value software. While story points and code maintainability metrics (like SonarQube) provide a starting point, they often miss crucial factors like team dynamics, waiting times, code churn, and the impact of knowledge silos. Metrics Machine is designed to fill in these gaps by providing a comprehensive set of metrics that reflect the health of your development process.

Why Metrics Machine?

We believe that the success of an Agile team is directly tied to the speed and quality with which value is delivered to production. Software Metrics Machine provides insights beyond traditional metrics.

Philosophy Drivers

• Continuous Feedback Loops: A constant cycle of observation, analysis, and adjustment is essential.
• Pipeline Health: Maintain a consistently green and stable development pipeline.
• Controlled Code Churn: Minimize unnecessary code changes, as they often indicate underlying issues.
• Knowledge Sharing: Actively avoid knowledge silos – encourage collaboration and knowledge transfer.
• Data-Based Technical Debt: Define and prioritize technical debt based on real data and impact.

Facets

This project relies on metrics that are extracted from:

• Pipeline
  • Success rate of pipeline ✅
  • Average time to complete pipeline from start to finish 🚧
• Pull requests
  • Average of Pull requests opened ✅
• Git history
  • Code churn ✅
  • Hotspots ✅
  • Change Frequency 🚧
  • Complexity Trends Over Time 🚧

You might be wondering, yet another developer complaining about story points, what is new? Lately, I have been thinking about how the classic metric about story points has been overused and misused (myself included) in software teams. Story points were created as a way to estimate the effort required to complete a user story, but they have become a jack-of-all-trades metric, even worse, a random metric. I have seen teams randomly assigning story points to tasks without any real understanding of what they represent. This is just part of the problem.