Are You Using the Right Metrics To Measure Developer Productivity?

Checking things off your to-do list feels good. But that isn’t enough to produce meaningful results. Are you doing what matters in the most effective way possible?

Getting more done isn’t the same as being productive. Software engineering teams could be writing numerous lines of code but fail to ship a product.

So how do you measure software development productivity meaningfully?

What gets measured gets done, so it’s important to track the right metrics. With the right productivity tools and data, software development teams can understand their overall efficiency and ability to produce results.

But before we tell you what productivity metrics to track (and what not to,) we must set a solid foundation. Let’s start from the beginning…

Measure What Matters: Prioritize Your To-do List

Getting sh*t done feels good. But, getting the right sh*t done moves projects forward.

If you spend your time on the wrong tasks, you aren’t using your time effectively. 

The first and most critical step in improving developer productivity is to get your priority straight. Are you focusing on the most important task or the ones with the most dependencies?

Let’s call up President Dwight Eisenhower, who devised a simple way to decide what deserves our time and attention. The Eisenhower Box takes the guesswork out of what to do next and what you can eliminate from your to-do list altogether.

Agile project management already has some level of prioritization baked in, but it doesn’t mean team members don’t face competing tasks every day. Individual developers and engineering managers can use the Eisenhower Box to make sure they focus on the most important tasks.

Now you know what needs to be done, you can ensure that your team is spending their time most effectively on work items that will move the needle.

How Not To Measure Developer Productivity

Here’s the bad news: many programmers measure their productivity in a way that doesn’t help them become more effective. 

If you use the wrong measure of productivity, you could be doing more harm than good. These metrics are easy to game and don’t provide actionable insights for teams to improve the product development process.

Here’s what not to measure:

1. Lines of Code (LOC/SLOC)

Writing more codes doesn’t mean you’re building a better product. More source code could create more complexity and lead to a higher chance of error and future issues. 

Measuring the amount of code produced isn’t an effective way to understand team productivity. Focusing on quantity over quality may even incentivize developers to do worse work that results in a poor-quality codebase.

2. Hours Worked

Similar to lines of code, this measurement emphasizes quantity over quality. Yet, the most efficient developers accomplish more high-quality work in less time.

Additional work hours could even reduce average productivity per hour. People who overwork may suffer burnout and clock negative productivity, characterized by an increase in errors and oversight.

3. Bugs Fixed

This metric is easy to game. Developers can pick the low-hanging fruit to increase the number of bugs they check off the list.

As a result, nobody wants to touch the big hairy bugs that require more time and effort. Deterring engineers from tackling critical issues is not an effective way to improve the quality of your product.

4. Task Completed

Not all tasks are equal in terms of complexity, the effort required, and most importantly, the impact on your project.

You can do 100 things a day and look “productive” on paper. But the busy work won’t amount to much if you’re avoiding meaningful or complex work that will move your project forward. 

Better Ways to Measure Developer Productivity

The inconvenient truth is that there’s no single metric or one-size-fits-all solution to measuring developer productivity. 

Your workflow, deployment methodology, team structure, development environment, software delivery process, and other specifics will impact how you measure team and individual performance.

But you can develop the right strategy and metrics for your team and individual developers to help them focus on the right tasks.

Measuring developer productivity typically boils down to tracking the work completed and the quality or importance of the task accomplished. By combining these two criteria, you can ensure that your team produces meaningful results.

Use metrics with a strong correlation with business outcomes (e.g., revenue.) They should address all output, including non-engineering work essential to the software delivery process (e.g., scoping, communicating with colleagues on Slack) while being resistant to people gaming the system.

These KPIs should be objective and independently verifiable. They should also allow you to compare performance across projects and understand individual productivity.

Here are some sample productivity metrics that can help developers focus on process and outcome rather than output:

• Pull request size
• Work-in-progress
• Time-to-open
• Code coverage
• Available tests
• Time spent on fixing bugs
• Average lead time from “on-hold” to accepted

The Caveat: Not All Metrics Have a Clear “North”

Many engineering managers overlook this consideration when they choose metrics to measure productivity—the type of work the developers are doing.

“High” numbers aren’t necessarily always good or bad. For example, some teams measure productivity as a function of tasks completed and technical debt created to ensure that teams are getting as much work done as possible without sacrificing code quality.

This approach makes sense in most cases but is technical debt always bad?

Technical debt is not bad if your team is ideating solutions and needs to test as many ideas as possible. It may even be desirable (and even necessary) to introduce more technical debt than usual to push the boundary.

The takeaway is that there are many ways to measure productivity using various metrics. No one system is guaranteed to work all the time. 

The best metrics for measuring productivity are likely to change depending on the type of work developers are doing, the nature of the project, and the development phases. 

As such, teams should evaluate their productivity metrics regularly to ensure that what they measure is indeed helping them optimize their efficiency and focus on achieving meaningful outcomes. 

Use Time Tracking To Enhance Developer Productivity

Most productivity metrics involve understanding how much time developers spend accomplishing each work item.

No doubt, time is important in the productivity conversation. But time tracking software development can be a double-edged sword because it’s easy to conflate expediency with meaningful work.

It can be tempting for development managers to jump on arbitrary productivity metrics to drive as much work as possible in less time. Yet, this can turn time tracking into a time-suck without achieving the ultimate objective of helping developers do a better job.

7pace Timetracker improves developer’s productivity by enabling engineers to own their data and leverage the information to understand their abilities and become more efficient.

When each developer is on track, teams can better understand development time associated with a specific number of story points (story size) and see how their skills improve over time.

Meanwhile, 7pace Timetracker records time where the work happens (e.g., on Azure DevOps and Github) — allowing you to assign time with each work item to gain accurate and granular insights on how the work happens.

For example, you can associate the time spent with different phases of a project and determine what metrics to use to gauge the efficiency and effectiveness of the effort.

Measuring productivity is complex. But with the right tools and metrics, you can gain the insights you need to track what matters.