5 Practical Software Development Metrics Every Agile Leader Needs

I’m sure you’ve heard of the saying, “Knowledge is power.”

It’s a great saying, and it’s not wrong. But it’s important to remember that the saying isn’t “More knowledge is more power.” Especially when it comes to evaluating the success and progress of your software development projects, it’s easy to get bogged down in tons of metrics, reports, and charts.

But what if I told you that you could simplify that evaluation process by looking only at essential software development metrics?

Let’s look at five practical Agile metrics you could use to steer your software teams to success even if you looked at no other metrics. These software development metrics are aligned with the Agile Manifesto, which focuses on individuals and interactions, working software, customer collaboration, and responding to change.

Essential Agile software development metrics you should be evaluating

Let’s explore what would happen if you chose a place to start, kept the software development metrics lightweight, and empowered your teams with more time to create valuable software instead of producing endless reports.

1. Customer experience using Net Promoter Score

If you were stranded on a desert island and could only bring one Agile software development metric, it should absolutely be the Net Promoter Score (NPS).

NPS asks one simple question: “How likely is it you would recommend us to a friend?” The customer responds by selecting on an eleven-point scale, ranging from “Not at All Likely” (0) to “Extremely Likely” (10). To calculate your overall score, just subtract the percent of detractors (negative red responses) from your percent of promoters (positive yellow responses). An NPS is an integer (not a percentage), so, for example, 60% would be an NPS of 60.

Hubspot has a great perspective on NPS: “Think of NPS, or Net Promoter Score, like rocket fuel. If you leave it alone, it won’t do much. But when you load it into a responsive, proactive, customer-driven company: blast off.”

Translating NPS into software priorities

Other than knowing the number (and either feeling bad or good about that figure), how can we as software leaders leverage NPS? Simple: verbatim analysis. Verbatim analysis means taking open-ended comments and categorizing them into themes.

MeasuringU has a great example of how to summarize verbatims without losing the rich detail of the user’s own words.

No Fear

Don’t be afraid to measure your NPS. Don’t be afraid to share it, at least internally. And don’t be afraid to make the changes necessary to respond to it.

2. Time to market using cycle time and lead time

Why did your organization begin its Agile journey in the first place?

If you’re like most organizations, you probably realized the value of shifting from bureaucracy to agility in order to “increase the speed of delivering ideas to market.”

Thankfully, measuring time to market (TTM) is relatively easy to do on your own or with the help of your Agile project management tool. Below, Stefan Wolpers offers a useful visual of the dates you need to record in order to measure your time-to-market via cycle time and lead time.

Resist the urge to set an arbitrary target number

When a software development metric like this first appears on a dashboard or in a presentation to management, the inevitable follow-up question is: “So what’s our company’s goal for time to market?”

Agile expert Esther Derby wisely states, “Be wary of target numbers. Measuring against targets almost always causes distortion. That means that people will behave so as to reach the target, perhaps in ways that are counter to the actual goal behind the target.”

Changing behavior in response to knowing you’re being observed is incredibly human. As an Agile team leader, the last thing you want is for your teams to consciously or unconsciously take shortcuts on testing or security measures in order to meet an arbitrary time to market goal.

Agility is a journey and a destination

Fundamentally, what matters most is your organization’s starting point and your subsequent improvements along the way.

You can use your teams’ time to market metric to see, at the highest level, how quickly your organization can turn an idea into reality.

3. Team satisfaction using a team health check

This whole “being successful in business” thing is a marathon, not a sprint—or maybe in Agile terms, we should say it’s a marathon made up of many sprints—which is why we list the team’s overall well-being as our #3 practical software development metric.

Old school command-and-control executives sometimes scoff at this metric. Fortunately, research proves that happy workers are more productive, make better decisions, and are more collaborative, creative and loyal.

Measuring another person’s happiness is tricky business

The debate on what to call it— whether it’s happiness, team morale, or something else—rages on. Whatever nomenclature you choose, start with a lightweight approach that feels right for the culture of your organization. Then inspect, adapt, and repeat.

If your organization is the type that can comfortably discuss individual and team emotions without a lot of eye-rolling, go for it. There are several ways to create mood boards broken down by teams and sprints, and it’s an excellent way to get the conversation going and spark change where necessary.

If your team prefers a slightly less touchy-feely measure, Spotify has written extensively about its Squad Health Check which uses two scales. Individuals color code their moods with green, yellow or red circles and, using arrows, rate whether things are getting better, worse, or remaining the same.

It’s not a competition

In the above example, Squad 4 is feeling good, and their outlook is positive while the current state of Squad 2 is fairly gloomy. However, this doesn’t necessarily mean that Squad 2 has an inferior leader, skills, or attitude. Instead, the organization should respond by asking, “How can we help?”

If you only had access to this single software development metric, you would have immediate insight into team productivity and the longevity of the teams’ current pace. You could even make some recommendations: change the scope of work for Squad 2 for a period of time, disperse that team into other projects, or assign them to the next up-and-coming hot project. And you would certainly know to ask the manager, “What does this team need to feel successful?”

4. On-time delivery using sprint burndown

In many organizations, as soon as a feature is committed to, those details are flowing both inside and outside the organization—whether you like it or not.

Sales, marketing, customer support, and executives all have a hand in letting the cat out of the bag. Whether feature details and dates are communicated purposefully to your customers, or whether they’re leaked out of the organization by an overenthusiastic sales engineer, they represent your commitments to the customer—features or fixes you have promised to deliver in a specified period of time.

That’s why on-time delivery via sprint burndown is our fourth practical software development metric.

The burndown provides a forecast of when you can expect all the work to be completed, and it shows velocity—an average amount of work done by a team over a given period of time. You can also look at the burndown chart to fix scope creep and add or remove tasks from the backlog.

5. Software quality using defect trends

Measuring software quality can be tricky. Some teams opt to measure quality only through ‘soft’ metrics, like customer satisfaction and revenue growth.

There’s no doubt that those are invaluable, but we run software teams. And so do you.

Therefore, we prefer to measure software quality according to the very literal number of defects that escape into production. This gives us some control over what we, as software teams, can directly impact.

Trouble in paradise

The defect trends report calculates the total number of bugs that have been opened and closed over time. It’s crucial for understanding the overall trend at which bugs are processed and helps gauge whether bug discovery and resolution rates are declining toward the end of an iteration, as expected.

If you feel that your defect trends report doesn’t give you the whole picture, it’s easy to combine defect trends with defect severity to get a more informed view.

Less is more with software development metrics

Could you simplify your existence and spend more time delivering value to your customers and less time running a myriad of reports? I think you could.

Starting with the five software development metrics above, you can do just that. And if you’d like to try out a tool that can give a head start on tracking and visualizing many of these measures, check out a demo of Targetprocess.

Although we think we’ve done a pretty good job of covering the essential software development metrics, we’d love to hear which Agile metrics you can’t do your job without. Let us know in the comments below!

Want to know more about tracking software development projects?

• Find out how to crank up speed in software development.
• Take a look at productivity metrics for your software development team.
• Looking to take Agile outside of IT? Start with these tips.