To use agile development practices in your project effectively, you need to measure performance. But how do you know what metrics to use and what you should be tracking? Read on for 8 metrics that will answer the right questions and keep your project focused on delivering business objectives. But first, let’s look more closely at the what, why, and how of software development metrics.

What are metrics in software development?

Software development metrics are ways to measure the performance and quality of software, teams, and methods. Traditional ways of measuring software projects looked at individual performance and meeting estimates. Agile software development instead focuses on team performance and tracking real business value. In place of hard deadlines and strict Gantt charts, agile development switched to burndown charts and lead times.

Why is it important to have software development metrics?

Metrics help you maintain control over a project and prevent it from going over budget and missing deadlines. Clearly defined metrics let team leaders know what to expect of their developers. Quantifying progress makes sense both for improving methods and assessing team effectiveness. Bottlenecks and weak points in processes can be identified much faster and easier if you’re tracking the right metrics.

How can you use metrics effectively?

You can most effectively use agile metrics by getting the teams involved in the measurement, by choosing metrics that will help them to identify problems as they work. This enables your developers to improve without waiting for management evaluations. Sprints are especially useful for this, as their short duration means that problems or successes can be dealt with early.

Now that we’ve explained some of the reasons why you should use software development metrics, let’s look at the actual metrics themselves. Here are 8 possible ways to measure your project effectiveness: 

8 metrics to track software development

1 Burndown

Charts are a great way of quickly understanding how much work is getting done. Agile development uses burndown charts to show work left to do versus time. You can use burndown charts on both the sprint and release level so that you and your team can see just how much functionality remains.

2 Lead time

This is usually tracked for each release and covers the time taken from idea to delivery of the software. To get even more insight, you should track this for each minimum viable product (MVP), so that your team can understand what to expect from themselves. Part of lead time is cycle time, which measures how long it takes your team to finish an item (represented by an issue, ticket, or card in a tracking system such as Jira). 

3 Team velocity

Story points are a way to estimate the amount of effort that a particular item - a feature, task, or any piece of work - will take. Story points give your team some sense of the difficulty of the story. Team velocity is a way to measure how rapidly the team can complete story points in each sprint. 

By tracking the number of story points completed, the team can self-assess how many story points they can reasonably expect to complete in the next sprint. While not considered part of team velocity, open/close rates perform a similar task, in that they track how much time it takes from an issue being reported to being closed. 

Find out more on story points and other items in the "Epic, Story, and Tasks in Agile" article.

Like all agile performance metrics, none of these should be used as a way to harass or hurry the team. If you see that there are slowdowns or bottlenecks, discuss it with the team and identify whether anything needs to change. 

4 Code coverage

Testing is an essential part of software development, and code coverage tells you how much of your code is covered by automated testing. You measure code coverage in percentages, so if you have 70% code coverage, 30% isn’t being tested. 

Code coverage won’t necessarily tell you how good your code is, but it will tell you how well you are testing the software. Reaching 100% can be the ultimate goal, but remember that there are always ways to improve how you test code.

Read about Software Testing Life Cycle here.

5 Mean time between failures (MTBF)

Maintenance is an important part of making sure that your software is performing as efficiently and reliably as possible. A valuable way to measure this is to determine the MTBF, a metric that has crossed over from traditional manufacturing and engineering. MTBF uses a simple formula.

MTBF = no. of operational hours / no. of failures

So if you have a product that has been in operation for 4000 hours and it stopped working five times in that period, its MTBF is 800 hours.

6 Mean time to recover/repair (MTTR)

Mean time to recover follows on from MTBF, in that it tracks how long it takes the maintenance team to fix failures. Again, it’s easy to calculate.

MTTR = maintenance time / no. of repairs

So if the team has spent 100 hours on unplanned maintenance in the period of time being tracked and the product has failed five times, the MTTR is 20 hours.

This can tell you a lot about how well the codebase was initially designed and documented. If the MTTR is comparatively high, it may indicate that the project could have been better optimized.

MTTR can also be used for tracking security metrics, as it represents how long it takes before a security breach can be fixed.

7 Application crash rate

If your software crashes a lot, the product is not serving its users well. The crash rate will give you some insight into the frustrations of users who do not go on to report bugs or issues.

You can calculate crash rate for any period, but let’s go for 24 hours:

No. of crashes in past 24 hours / no. of sessions in past 24 hours * 100

If users launched your app 400 times in the past 24 hours and it crashed 50 times, you’ve got a crash rate of 12.5% and you should do some optimization or bug fixing.

8 Endpoint incidents and other security metrics

Security will often be one of the biggest concerns for your clients, so you need to track how safe it is for them to rely on your product. In fact, endpoint security is usually so vital that your software will probably not be allowed to interact with other systems if it doesn’t reach a certain standard, usually represented by endpoint incidents. 

This metric tells you how many endpoints, or devices (workstations, portable devices - anything that runs your software), have experienced a virus infection, incursion, or another security failure over a particular period of time. Low endpoint incident numbers and fast response times on the part of your maintenance team are crucial for reassuring your customers that you take security seriously.