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. Code 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.

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.

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.

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.

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.

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.