5 Developer Metrics Every Software Manager Should Care About

September 30, 2016

Measuring a development team’s productivity is one of the most difficult challenges that software managers currently face. Many managers advocate a range of complex metrics to assess productivity, while others use no metrics at all.

In our experience, we've found the following five developer metrics are essential for all software managers:

  1. Lead Time
  2. Churn
  3. Impact
  4. Active Days
  5. Efficiency

The good news? These developer metrics can be derived from version control data that's in your GitHub/BitBucket/GitLab or other code repository. Metadata from these modern code repositories provides real-time insights into engineering work patterns and the health of your team.

1. Lead Time

Lead Time is the time period between the beginning of a project’s development and its delivery to the customer. Your development team’s lead time history will help you predict when an item will be ready with a high degree of accuracy.

Use lead time to help you predict when an item will be ready

This data is even useful if your development team doesn’t routinely provide estimates, since the predictions can be based on the lead times of similar projects. As an example, assume that 50 percent of similar feature request had a lead time of two weeks or less, and 90 percent of these projects had a lead time of one month or less. You could confidently provide a lead time of one month for the current project.

2. Code Churn

Code Churn is the percentage of a developer's own code representing an edit to their own recent work. It’s typically measured as lines of code (LOC) that were modified, added and deleted over a short period of time such as a few weeks. The primary purpose of measuring churn is to allow software managers and other project stakeholders to control the software development process, especially its quality. When churn starts to spike, this can be an indicator that something is off with the development process.

Measure churn to indicate when something is wrong with the development process

For example, imagine a situation where a developer receives a very opaque set of requirements, like “the app needs settings” — something that’s not uncommon when working with product stakeholders. When this disconnect turns into weeks worth of iteration on the same feature without a lot of forward progress, that will show up as code churn. Churn rate can also help to identify problems with individual developers. For example, a sudden increase in churn rate may indicate that a developer is experiencing difficulty in solving a particular problem or is repeatedly polishing a feature that’s ready for release. A high churn rate may also mean that a developer is under-engaged. Other causes of high churn include an indecisive product team that has the developer running in circles. For more, check out 6 causes of code churn and what to do about them.

3. Impact

Impact is a measure of the effect that code changes have on your project, and a way to consider the cognitive load they place on the developer who implemented them. Change sets that are more difficult to implement will therefore result in a higher impact score. The impact of a change set depends on a variety of factors such as the amount of code in the changes, the severity of those changes and the number of files that the changes affected.

Impact is a better way to measure your engineering team's progess

For example, adding 100 new lines of code to 1 file, could have much less impact than a change with far fewer lines affected if it includes multiple insertions and deletions across multiple files. You could also compare the current impact values with the historical values to determine the effect of a recent change set.

4. Active Days

An Active Day is a day in which an engineer contributed code to the project, which includes specific tasks such as writing and reviewing code. Engineers are uniquely skilled at building and solving difficult conceptual problems, so contributing code is one of the most important things that an engineer can do. Non-engineering tasks such as planning, meetings, and chasing down specs are inevitable. In fact, most teams lose at least one day each week to these activities.

Use active days to see the hidden costs of interruptions

Calculating this type of data allows you to see the hidden costs of interruptions, like how an all-hands meeting in the middle of the week affects overall productivity. With Active days, you can protect your team's attention and ensure process-overhead does not become a burden.

5. Efficiency

Efficiency is the percentage of an engineer’s contributed code that’s productive, which generally involves balancing coding output against the code’s longevity. Efficiency is independent of the amount of code written.The higher the efficiency rate, the longer that code is providing business value. A high churn rate reduces it.

Measure your developer's efficiency to understand their work pattern

Different types of engineers will have different efficiency rates.A engineer that is trailblazing a new solution may try a lot of paths in the discovery phase, and a low efficiency rate may be expected. The most prolific engineers contribute lots of small commits, with a modest churn rate, resulting in a high efficiency rate. Understanding an engineer's typical efficiency rate can help you understand their character and where they will fit in best.

That wraps up our take on essential developer metrics. We suggest focusing on these particular metrics because you can’t track everything, and not every measurement is a key metric.