How To Track Developer Productivity

In this economy, you’re undoubtedly getting pressure from your execs about how to track developer productivity. And you need to figure out how to do more with less. 

So how do you reassure your stakeholders that you have a grasp on your developer productivity, where it needs focus, and how you’re going to improve it? It’s crucial to monitor the right productivity metrics because you can’t improve what you don’t measure. 

This article will define developer productivity, address some common myths surrounding it, and cover ways how to measure it. Let’s dive right in.

Table of Contents

• What is Developer Productivity
  • Common Myths about Dev Productivity
  • Developer Productivity and the SPACE Framework
• How to Track Developer Productivity
  • Correlate Data from Your Git and Project Management Tools
  • Start with the Basic Metrics
  • Benchmark Your Developer Productivity Against Industry Standards
• Start Improving Developer Productivity Today

What Is Developer Productivity?

Developer productivity refers to an engineering org’s efficiency in releasing high-quality code that delivers value. Tracking productivity involves a variety of metrics, and choosing the wrong metrics to define productivity in an engineering org is a common pitfall (*cough, cough* like at Twitter *cough, cough*). 

Let’s take a look at other common myths and misconceptions around measuring developer productivity.

Common Myths About Dev Productivity

Myth 1 – Activity = Productivity 

In many companies, productivity is measured by the number of projects, features, or lines of code devs can deliver. More output, more success. However, these measurements don’t consider the quality of the code or how closely the activity aligns to the defined scope of the project.

If you are not measuring the quality of those tasks or how the activity aligns with the broader business goals, you may not be productive at all. You may be completing work that isn’t useful or creating more work via technical debt that you’ll have to pay back later. 

Myth 2 – Individual Productivity = Team Productivity 

Many software firms count the lines of code developers write to measure their productivity. But that’s not really ideal. Pushing developers to write more code doesn’t help that code get released to production any sooner. 

Software development is a team sport. And if you start stack ranking devs by individual metrics to determine productivity, you’ll actually tank it. Instead, you need to focus on outcomes. 

Team-based metrics like merge frequency and deployment frequency (more on these later 👇) are better measures of productivity of the whole org. And at the same time, you’ll be promoting efficient processes that speed up development time.

Check out this chat with Kathryn Koehler, Director of Productivity Engineering at Netflix, and learn whey she says measuring outcomes vs. outputs is a more effective way to track productivity.

Myth 3 – One Metric to Rule Them All 

This idea that there’s “one metric that matters,” and it can be used to score teams on their output and compare teams across an organization—well, it just isn’t true. And not only is not true, it’s extremely dangerous. LinearB COO, Dan Lines, has very strong opinions on how agile velocity has been viewed this way.

The truth is that engineering projects are multi-dimensional. You can’t uniformly measure all developers, all teams, and all types of output the same.

Myth 4 – Only Managers Need to Measure Productivity 

This myth likely comes from the misuse of productivity metrics by leaders or managers. Unfortunately, it’s all too common for engineering productivity to be poorly measured and misused.

But it’s important that your developers have insight into their own productivity. Ideally, they leverage it to make adjustments to their work, such as taking control of their calendar and focus time. And research shows that high productivity is directly correlated to developer experience (i.e. feeling satisfied and happy with work).

Developer Productivity and the SPACE Framework

The goal of the SPACE framework was to bust these myths and guide engineering organizations to a more holistic way of measuring developer productivity. Nicole Forsgren and a research team from Microsoft and GitHub used the acronym SPACE to define 5 dimensions of developer productivity:

• S: Satisfaction and well-being
• P: Performance
• A: Activity
• C: Communication and collaboration
• E: Efficiency and flow

It’s imperative for engineering leaders—and even executives—to understand that developer productivity is influenced by a wide range of factors and that problems in any of these areas will impact outcomes. 

How To Track Developer Productivity

Without the proper tool, quantifying developer productivity can be a daunting task. But there are three things you need to get started: 1) to correlate data from your Git and project management tools, 2) focus on a core set of metrics, and 3) be able to benchmark your metrics against industry standards. 

Let’s dig into each of these.

Correlate Data From Your Git and Project Management Tools

The typical mistake engineering leaders made trying to track developer productivity is trying to get all the data from their project management tool. Unfortunately, all Jira reports have crucial limitations: 

1. they can only leverage Jira data
2. they require good hygiene to really be useful, and 
3. getting all the need-to-know information in a single executive report takes a lot of work

Project management data may show you that an issue or project is behind schedule or how your team has performed over time. But it doesn’t provide you enough context to answer the “why.”

By correlating project management & Git activity, LinearB gives you a consolidated view of your productivity and a new depth of insights—presented in a way that every stakeholder can understand.

Start With the Basic Metrics

Developer productivity should be measured in both quantitative and qualitative ways. There are 3 main categories of metrics you should start with: DORA metrics, developer experience metrics and business alignment metrics. 

DORA Metrics

The DevOps Research and Assessment (DORA) group conducted one of the most influential studies on the topic of developer productivity. Over the course of six years, they polled thousands of DevOps leaders and engineers to determine the four most important metrics for measuring team velocity and the stability of software development projects. Those four metrics are:

1. Deployment Frequency – Measures how often code deploys into production. And it’s typically reported in deployments per day or deployments per week.
2. Mean Lead Time for Changes (aka cycle time) – Calculates the average time from first commit to production release. It’s divided into 4 distinct phases: coding time, pickup time, review time, and deploy time. And it gives you a better understanding of bottlenecks and inefficiencies in your workflow. 
3. Mean Time to Recovery (MTTR) –  Measures the average time recovering from a production failure or outage. It can be defined alternatively as the time between the report being created and the fix being deployed to production.
4. Change Failure Rate – Tracks the percentage of code changes or deployments that lead to failures in production. Changes that result in a rollback, in production failing, or in production having a bug all contribute to this metric.

Developer Experience Metrics

Metrics that measure developer experience (DX) can also lend some insight into productivity. While there may be some ambiquity in measuring developer satisfaction, there are plenty of quantitative markers that can help you determine if team members are overloaded or generally unhappy. The 4 DX metrics are:

1. Work in progress (WIP) – When your team is overstretched or balancing too many projects, errors and fatigue jeopardize productivity. Monitor the active branches and individual dev’s WIP load to help prevent burnout and mistakes. 
2. Active Days – When your developers are working six and seven days in a row, you jeopardize their overall productivity. By tracking active days, you and your managers can remind team members when they’re not taking enough time to rest. 
3. Pull request (PR) size – Fun fact: PRs less than 200 lines of code get reviewed 10x faster. Not only are large PR reviews often more complex, they often mean your reviewers could be correcting the same error several times. Keeping PRs small shortens the feedback loop and prevents dev frustration and toil.
4. Merge frequency – This measures the total number of pull requests or merge requests merged by a team over a period of time. A high merge frequency indicates a healthy pipeline and a lack of PR lifecycle bottlenecks that frustrate developers.

Business Alignment Metrics

Developer productivity should also be measured by looking at how well engineering deliverables align with the needs of the business. The development team and company leaders can speak the same language, thanks to these metrics. Three key performance indicators (KPIs) can help you evaluate how well your engineering team is doing and how closely they align with what the company cares about.

1. Investment profile – This chart breaks down the work by issue types. It helps you determine if the engineering team is investing in the right types of work. Armed with this info, you can better balance competing priorities to deliver the best results for your customers and company. 
2. Resource allocation – Resource allocation reports connect engineering projects and strategic epic investment to people effort in a simplified view that every stakeholder can understand. This context makes discussions about balancing competing priorities and finite resources easy.  
3. Planning accuracy – Planning accuracy is the ratio of the planned and completed issues or story points out of the total issues or story points planned for the iteration. And planning accuracy breakdown reports identify the things that prevent you from delivering on your promises, like unplanned work or carryover work. 

With LinearB’s Project Delivery Tracker, you can view all 3 of these metrics.

Benchmark Your Developer Productivity Against Industry Standards

Once you have baseline developer productivity metrics like the ones above, you’ll want to compare your teams’ performance toothers in your industry and then use this information to pinpoint areas that need improvement.

Our Engineering Metrics Benchmarks study provides you with the first report of this kind. After analyzing almost 2K engineering teams and over 800K branches, we identified four tiers (Elite, Strong, Fair, Needs Focus) for nine engineering metrics. 

These benchmarks are baked into our developer productivity platform, so right out of the box you can track your developer productivity and create working agreements about what needs to improve.

Start Improving Developer Productivity Today

Now that you know how to track developer productivity and identify areas for improvement, you need a platform that can also help you improve. Improving developer productivity starts with developer workflow optimization, which means helping developers shave time off non-coding tasks through automation and get back to doing what makes them happy, coding.

The LinearB platform includes two types of developer workflow automation tools: WorkerB and gitStream. Paired with our benchmarks and Team Goals features, this creates an easy-to-follow 3-step recipe for developer productivity improvement in a single tool.  

But don’t take our word for it. Check out how our customer, Hippo, increases productivity using LinearB.