Productivity Metrics You Should Use (and what to ignore)

Productivity is quite a buzzword.

But what does it mean in today’s context where many of us, such as software developers, create value by developing intellectual capital rather than tangible or immediate output?

Productivity should correlate with qualitative outcomes instead of quantitative output.

Yet, many organizations still use old-school productivity metrics that focus on quantitative output. These KPIs (e.g., lines of code per month, the number of commits, the number of tickets closed) don’t align with the value we produce or what motivates us to do our work.

Productivity metrics that don’t reflect the value of our work prevent us from doing what’s most impactful. In fact, they can be counterproductive when it comes to helping us focus on creating high-quality outcomes.

So how can we measure productivity within the context of intellectual work to stop chasing KPIs that are killing our morale and motivation? Let’s get to the bottom of it.

What’s Wrong With Productivity Metrics?

Most productivity KPIs are problematic for developers because:

• They don’t tell the whole story: Most productivity metrics ignore the critical context of where, how, and why the work is done. In software development, many of them also fail to account for intangible factors such as intellectual capital (e.g., learning a new coding language or experimenting with new workflow) and innovative work that are crucial to long-term success.
• They may not correlate with revenue: Productivity metrics that encourage busy work can hurt business outcomes. For example, two engineers can build an identical feature with a vastly different code volume. The product with more lines of code isn’t better and it’s harder to maintain. As such, using “lines of code per staff per month” as a KPI is counterproductive.
• They’re hard to tie to individual contributors: Some measures, such as staff hours spent on defining requirements, maintaining hardware, and reducing technical debt, are essential to the success of a project. Yet, they aren’t reflected in an individual’s performance.
• They’re easy to manipulate: It’s tempting to game some of these measurements. For example, if you use “time to review code” as a metric, reviewers may become less thorough so they can look good on paper. Meanwhile, developers can make their “pull request counts” look good by making small changes that require less work.
• They may deter engineers from innovating: Experimentation and innovation require us to try different things that may not yield tangible output right away. Traditional productivity metrics fail to account for these important activities that allow us to gain new insights that can’t be tied to a specific output.

How to Identify Meaningful Productivity Metrics in Software Development

We’re all about tracking our work to help us become better at what we do. This means identifying metrics that matter to measure the impact of our work.

Your metrics should have a strong correlation with a business outcome (e.g., revenue) and address all work output. They should incorporate non-engineering work and be resistant to people gaming the system.

These KPIs should be objective and independently verifiable while giving you the ability to compare performance across projects. They should be easy to measure and help you understand the capabilities of each team member.

Here are some KPIs to help you 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

It’s important to choose metrics that can help you focus on what matters. For example, if you measure  “time to fix bugs,” you may be tempted to pick easy bugs to make the numbers look good. You can better gauge your productivity by measuring “time spent on fixing bugs.”

But There’s More! Our Secret Weapon: Pace

There are many ways to measure productivity, but not all of them are meaningful within the software development context. In fact, some are even counterproductive.

For example, tracking the number of hours worked without correlating it with outcomes doesn’t help you understand if you’re using your time productively to create meaningful results.

Moreover, they don’t give you the insights to improve your process, so you can make better estimations to optimize the quality of your output.

Here at 7pace, we have developed a metric specific for software developers to help them manage their effort in the development process.

This KPI is called pace. To calculate your pace, simply divide time spent on a task by the estimated effort (i.e., story points.)

Since pace is a function of the estimated effort to achieve a specific outcome, it automatically helps us focus on how much time we need to create meaningful results.

To start, calculate your average pace using data from past projects and use this as a baseline to make estimates for future projects. Then, track your time, divide it by the story points for each task, and refine your number.

You can also use pace to help you catch issues. For example, if there’s a substantial discrepancy between the pace of a task and your average number, you can revisit the scope or timeline right away to address roadblocks.

So, what’s a good pace?

We didn’t develop pace as a metric for micromanagers to hold over a developer’s head. In fact, it’s all relative, and there’s no absolute right or wrong answer to what’s a good pace.

If everyone in your team is happy with the pace and you’re producing the intended outcomes, that’s a good pace for your team.

How to Measure Pace Accurately

The good news is that there are only two variables in the equation. But you must track the data accurately.

This means you need a foolproof way to record the time spent on each task, associate it with the estimated effort, and apply it to the formula.

There are two ways to measure pace: You can use the formula and calculate pace manually, or use 7pace Timetracker to log your time and have the metric auto-magically calculated for you.

We have designed our Timetracker to help developers get the metrics they need to measure their development process and create meaningful outcomes.

Learn more about 7pace Timetracker and see how it can help you better manage your time and improve productivity in a meaningful way.