4 Software KPIs to Track and 4 to Lose

“Time is money.” In business, this axiom has underscored the pursuit of productivity and efficiency at every level. Software is no different. It’s one of the fastest growing industries today and buoyed by ever advancing technologies. There’s no sign of it slowing down. To keep up with growing demand, modern software development managers often look to software KPIs to track team performance and improve their workflows. With so many possible KPIs to choose from, it can be hard to know which to keep track of. In this article, we’ll go over the top 4 software KPIs to monitor to improve performance and the 4 you can do without.

What are KPIs in software?

Software KPIs are performance metrics derived from data generated throughout the software development process. They’re typically used to gain better insight into how software development teams are performing.

Most KPIs follow S.M.A.R.T. principles to provide useful information on the software development process in relation to defined targets. 

What are the benefits of Software KPIs?

Identifying and tracking software KPIs allows software teams and managers to:

• gain visibility into the processes, resources, and environments in use in the SDLC
• forecast capacity and time needs for upcoming projects
• evaluate the status of ongoing projects.
• improve team performance by pinpointing and addressing inefficiencies and blockers.

While looking at Software KPIs as snapshots of development performance can be useful, it’s hard to gain insights without context. The real value they offer, lies in uncovering trends over time. 

When used like this software KPIs can be leveraged to optimize development. This can lead to better ROI by:

• reducing wasteful practices in development
• optimizing workload management
• improving process efficiency

With historical context, it’s possible to see how different aspects of the development process change. These changes can highlight areas for improvement or, conversely, show where development is most productive. 

Commonly used Software KPIs

Over the years, several metrics have been proposed for measuring team productivity in the SDLC. 8 Commonly used Software KPIs include:

• Team velocity
• Cycle time
• Throughput
• Maintainability
• Burndown Charts
• Code Coverage
• Code Stability
• Code Churn

However, there are many more used by different software development teams to suit their specific use cases. 

One of the biggest mistakes many businesses make when trying to become more data-driven, is tracking anything and everything. While it’s tempting to take Peter Drucker’s famous line and run with it, being judicious with your KPIs is often a more useful approach.

Without the right tools on hand, collecting data and calculating the software KPIs you want can cost you time and resources. It can also be difficult for devs to measure what they’re doing while they’re working. That’s why having the right tools to gain a clearer view into your development can help.

4 Software KPIs you should be tracking

The most useful KPIs are those that offer actionable insights into areas of your software development that have a direct impact on value generation. This knowledge can then be leveraged to identify areas for improvement in development.

To that end, 4 Software KPIs that have a direct impact on your bottom line are:

1. Change Lead Time

Change lead time should not be confused with lead time. While it can be confusing, Change lead time is part of the overall lead time for a project. Where lead time measures the time taken from the start of a project to its completion, change lead time measures the time it takes for code commits to be deployed in production. It’s a great way to see how long it takes for code written to see use as finished products. 

Change lead time contributes to cycle time, which in turn contributes to overall lead times. As a metric, it’s especially useful for identifying bottlenecks in development. Where change lead times are lagging, there are likely inefficiencies at play. Addressing those inefficiencies or friction points can help your teams to improve their overall speed and agility. The faster teams can mobilize and complete new features or resolve issues, the happier your customers will be.

2. Mean Time To Recovery (MTTR)

The mean time to recovery (sometimes called “mean time to restoration”) is a way to measure team responsiveness and agility. Typically, it’s measured as the time taken to restore service after unplanned product or service outages divided by the total number of such failures. For example, if your team spends 60 hours per year fixing unplanned downtime and your product has experienced 10 failures throughout the year, your MTTR for that year would be 6 hours. 

MTTR can be calculated on a yearly, quarterly, or monthly basis and used to establish baselines for team performance. Efforts to reduce MTTR can include improving response time or addressing the root causes of outages in development. Like lead time, MTTR has a direct impact on customer satisfaction and customer success.

3. Deployment frequency

Deployment frequency is one of the core metrics for DevOps-based software development. It measures how often teams are deploying code to production environments. For Continuous Integration/Continuous Development, code deliveries aim to be smaller, faster, better tested, and more easily maintainable. Seeing how your team is deploying code can give a good sense of how agile their performance is.

When deployments are consistently slow or infrequent, it may signify issues in development that need to be addressed. On the other hand, frequent deployments signify efficient and productive teams. Measuring deployment frequency over time is a good way to map trends in development and identify outliers.

4. Defect Detection Rates

Defect Detection Rates is a measure of how many bugs/defects are detected per file or area of code in a project. Tracking the number of defects provides insights into code quality and QA performance. This should include the number of defects found both in development and in production.

Tracking the number of defects historically can provide insights into team effectiveness but be wary; Low detection rates don’t always mean the product is good. It could simply mean that fewer defects have been detected. It’s a good idea to follow up on the defects and how they’re being resolved.

How NOT to measure developer productivity

While there are many software KPIs and metrics available, they can often vary in usefulness. To put it bluntly, the metrics you should pay less attention to often fail to offer up actionable information or track phenomena that impacts value generation. Unproductive metrics like these might also demotivate productive employees and are susceptible to gaming.

KPIs that you might want to re-consider using are:

1. Code Volume / Lines of Code (LOC)

Lines of Code is the metric that developers love to hate. It refers to the amount of code that developers produce. On the surface, this can seem like a good way to gauge their productivity, but it’s far from perfect. Devs can easily fluff this metric with needlessly verbose code. 

Incentivizing devs to produce more lines of code also contradicts the K.I.S.S. principle of good programming by creating needless complexity. What makes LOC problematic as well is it ignores important realities of programming. For example, the most powerful solutions can sometimes be written in only a few lines of code, and sometimes, large amounts of code need to be deleted when refactoring.

2. Number of Tickets Closed

While managers may like this KPI as a measure of work being done, the number of tickets closed can lack nuance. The size, complexity, and impact of tickets don’t often get weighed or shown the appropriate attention. If devs are aware that ticket numbers are being assessed, they will certainly close tickets, but which ones? 

Larger, more cognitively demanding tasks can take much longer to resolve leading to lower numbers of tickets closed for the devs they’re assigned to. For example, a front-end dev working on relatively minor UI tasks can likely close 10 to 15 tickets in a day. Compare that to a back-end developer building an API to serve user needs at scale. They might take a week to close that ticket but create far more actual business value.

3. Number of Commits

Like Lines of Code, the number of commits attempts to measure the “quantity of work” done by developers. However, focusing too heavily on the number of commits can encourage practices that harm productivity.

The number of commits often fails to measure the size or the impact of work done. A dev can make 100 commits with minor changes and still appear to be doing more work than the developer making 1 large commit with 45 new lines, and 20 updated lines of code. In theory, the number of commits looks good, but it fails to accurately reflect developer efforts. A more well-rounded view would look at the size and complexity of changes and use that to estimate the amount of work done.

4. Number of Bugs Fixed

The number of bugs fixed can be a controversial KPI in development. On the one hand, finding and resolving bugs is always good, as it shows progress toward a better product and greater customer success. On the other hand, it tells observers very little about the nature of the bugs fixed. Were they complex, deep issues that affected product functionality or were they relatively minor UI/UX defects? 

In development teams where KPIs contribute positive evaluations, the number of bugs fixed essentially rewards developers for fixing problems they’ve created. What’s more and as a simple measure of quantity, it fails to address why the bugs were there in the first place. If the number of bugs fixed affects performance reviews, some developers might become incentivized to test less and prioritize solving less-challenging defects.

Dig Deeper into Development with Software KPIs

The Software KPIs listed above are a great place to start re-evaluating your approach to measuring software development productivity, but they’re not the be-all and end-all of the matter. Software development is often more nuanced than 4 KPIs can describe. If anything, they provide a good starting point for understanding your development.

Process and outcome KPIs can offer top-down views of productivity and performance, but a more holistic approach means gaining visibility into development at the code level. This requires digging deeper and getting a more in depth understanding of your products. To do that, you’ll want to look at your software’s code health and what your developers are contributing to the process.

Use your KPIs to create better development

As teams strive for faster, higher-quality development, tracking KPIs is only half of the battle. The need for efficiency and effectiveness in the development process can only be met with better process management and better planning. More effective planning empowers teams to navigate the development process more smoothly and systematically. Learn more about how teams can improve their software engineering planning here.