5 Developer Metrics Every Software Manager Should Care About

Sep 30, 2016 | Leadership, Perspectives in Engineering

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. [For more on Lead Time and Flow, see our post: Boosting Engineering Productivity by Managing the Development Pipeline]

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.

What metrics do you track in your organization? We’d love to hear your opinion and the metrics you find most valuable. Contact us at ideas@gitprime.com

 


 

Travis Kimmel

Travis Kimmel

Travis Kimmel is the CEO, co-founder of GitPrime, the leader in data-driven productivity reporting for software engineering teams. He is experienced in building high-performing teams, and empowering people to do their best work of their careers. Follow @traviskimmel on Twitter.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

how to use data to lead a successful software teams

A Data Driven Approach To Leading Software Teams

Learn how engineering leaders are using data to help their team increase productivity and become even more effective. We've analyzed over 40 Million commits to help you understand the important questions every software engineering manager needs to know.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This