17 software engineering metrics + how to track them

Software engineering metrics are a way to measure the quality and health of your software development process. These metrics should be objective, simple to understand, and consistently tracked over time.

While teams may try to “game” the metrics in their organization, this will end up hurting your team in the long run. Software engineering metrics should be used as objective signals to drive better outcomes for your organization.

It’s important to note the difference between software engineering metrics and application and performance monitoring (APM) metrics. APM metrics (like website uptime) track the actual performance of a piece of software or app. Software engineering metrics, on the other hand, measure team performance, team health, and delivery predictability.

While Jira metrics provide a solid foundation for tracking fundamental Agile metrics, they don’t encompass all aspects of the software development lifecycle.

Jira metrics lack depth and highlight surface-level issues rather than showing leaders how to improve organizational performance. Tools like Pluralsight Flow merge various software engineering metrics to provide you with a deep dive into historical trends, team health, and collaboration to help you identify bottlenecks in your process.

There are a number of software engineering metric types to focus on as a team. At the heart of these metrics, you want to look at how well your team is hitting goals and developing productive code.

Software engineering metrics fall within a few distinct buckets and map to certain aspects of the software development lifecycle:

• Predictability: Metrics under this category answer the questions “Are we moving fast enough?” and “Do we have a steady, efficient pace?” Understanding these metrics enable leaders to more predictably estimate outcomes, timelines, and ROI.
• Activity: These metrics—when used properly—can show how organizational inefficiencies are getting in the way of work getting done.
• Culture: Culture metrics answer the question, “Are we instilling a collaborative culture in our software development process?” Pull request metrics are key to seeing how collaborative your team is during the code review process.
• Efficiency: These metrics evaluate how efficient your team is, whether there are processes or roadblocks hurting your team, and whether developers are taking feedback from their pull requests and iterating on it.
• Reliability: Reliability metrics work as a sort of control variable to help teams understand if they’re sacrificing quality for speed.

Coding metrics allow developers to track and measure the quality of code they’re creating. Tracking this historical data provides the insights teams need to improve the reliability and maintainability of code.

Lead time for changes measures the time it takes from when code is committed to when it’s deployed. This metric gauges how long it takes to create and deliver value to the user.

A high lead time for changes can indicate there are bottlenecks within your software development process. A low lead time for changes shows that your team is efficient in reacting to changes—whether it’s responding to feedback, fixing a bug, developing a new feature, or maintaining your codebase.

Deployment frequency measures how often code is successfully deployed into production. This metric measures a team’s speed and agility. Teams deploying more often (such as several times a day or once a week) indicate elite or strong-performing teams.

If your team is deploying less frequently (such as once every few weeks), it may be a sign to reduce your deployment size so it’s easier to review, test, and deploy.

Rework is code that’s rewritten or deleted within three weeks of being created. While some rework is to be expected, spikes in rework can indicate that an engineer is struggling with a project or that a project’s requirements were unclear. For a senior engineer, a typical rework rate is between 20 – 30%.

Impact measures the scale of changes to the codebase. This metric is an approximate measure of the cognitive load the engineer carried when implementing code changes. Impact is a good explainer metric—if efficiency or coding days drops, was it due to work with above-average complexity?

Impact takes into account:

• The amount of code in a change
• What percentage of the work is edits to old code
• The number of edit locations
• The number of files affected
• The severity of changes when old code is modified
• How this change compares to others from the project history

Legacy refactor measures the updates and edits to code older than three weeks. Tracking this metric helps you better understand how much time is spent paying down technical debt.

New work is brand-new code that doesn’t replace or fix other code. This metric shows the amount of code a team or individual writes for new products and features.

Your new work target will depend on the stage of business you’re in. For example, a new company might aim for more than half of their work to be new work, indicating you’re building a new product.

Commit complexity measures how likely it is that a particular commit will cause problems. This metric calculation includes how large the commit is, the number of files it touches, and how concentrated the edits are. Commit complexity essentially looks at the riskiness associated with a commit.

Commit complexity is an important metric to track because it can help teams prioritize which commits to review first—and which commits will require extra time and attention.

Team collaboration metrics give managers crucial insight into how teams are responding to the code review process. These metrics provide insight into the overall collaboration and team culture, as well as bottlenecks impacting deployment.

Responsiveness is a measure of how long it takes a submitter to respond to a comment on their pull request with another comment or code revision. This metric gives teams insight into whether team members are responding to code review feedback in a timely manner.

Lowering this metric ensures that pull requests are being reviewed and merged in an appropriate time frame. For context, the industry norm for leading contributors is 1.5 hours and six hours for typical contributors.

Unreviewed PRs is the percentage of pull requests without comments or approvals. This metric shows you how many pull requests are merged without being reviewed.

Leading contributors typically have 5% unreviewed PRs, and typical contributors have 20% unreviewed PRs.

PR iteration time is the average time in hours between the first and final comment on a pull request. This metric gives you insight into how long it takes to implement changes requested on PRs.

High iteration time can indicate the initial pull request had poor or misaligned requirements or that the reviewer’s requested changes were time-intensive and out of scope.

Iterated PRs is the percentage of pull requests with at least one follow-on commit. This simple metric allows you to see how many pull requests require additional work before being merged.

Reaction time is the time it takes for a reviewer to review a pull request and respond to a comment. This metric helps answer the question: Are reviewers responding to pull requests in a timely manner?

The goal is to drive this number down, as a lower reaction time indicates better collaboration between submitter and reviewer. A typical reaction time for a leading contributor is six hours, and 18 hours for a typical contributor.

Thoroughly reviewed PRS is the percentage of merged pull requests with at least one regular or robust comment. This metric aims to ensure pull requests are being thoroughly reviewed.

Too many pull requests without thorough reviews can be a sign of rubber-stamping during the code review process. On the flip side, a high thoroughly reviewed PRs percentage indicates strong code review quality and healthy team collaboration.

Time to merge is the average time in hours from when pull requests are created to when they’re merged. This metric tells you how long pull requests are in review. Long-running pull requests can be costly to your business and result in delayed releases.

Time to first comment is the average time in hours from when pull requests are created to when they receive their first comment. Driving down this metric helps reduce waste, cycle time, and context switching.

Follow-on commits measure the number of code revisions added to a pull request after it is opened for review. Tracking this metric gives you insight into the quality of your code review process. If you see a spike in follow-on commits, that’s an indication you may need better planning and testing.

Sharing index measures how information is being shared across a team by looking at who’s reviewing whose pull requests. Tracking the sharing index can help you understand the number of people regularly participating in code reviews.

This metric is a great way to gauge how well senior members are sharing knowledge with more junior developers and identifying situations where knowledge silos are happening.

The goal of tracking these metrics should be to improve processes, quality, and collaboration across your team. The benefits of tracking software engineering metrics include:

• Increasing understanding of how work is being done
• Identifying problems/bottlenecks
• Managing workloads and resources
• Drawing objective conclusions to aid in decision making and goal setting

Of course, it’s not enough to simply track software engineering metrics. You must also make it a habit to report on and review these metrics on a regular basis to track growth over time.

With so many metrics to track, it can be helpful to take a step back and consider your organizational goals as you’re determining what metrics you want to prioritize.

One way to do that is with the Goal/Question/Metric method. This method is broken down into three levels:

• Goals (conceptual level): Start by defining the goals you’re trying to achieve.
• Questions (operational level): Ask clarifying questions you’re trying to answer with the data you collect.
• Metrics (quantitative level): Assign a set of metrics to every question to answer it in a measurable way.

Goal/Question/Metric can be used for a variety of outcomes. You may want to use the method to improve technical quality, product quality, or delivery team health. Using Goal/Question/Metric will ultimately help you identify and clarify your business goals, and establish metrics that will help you track and measure progress toward these goals.

You can measure almost anything, but you can’t (and shouldn’t) pay attention to everything. Pluralsight Flow helps you track the right metrics all within one DevOps metric dashboard to give you the workflow insights you need.

To find out more about how Pluralsight Flow can help you track metrics beyond the standard Jira or DORA set, schedule a demo with our team today.