Engineering Metrics Program

Quick Start Kit

Welcome, Dev Leader. This site has everything you need to start your engineering metrics program in 40 minutes or less. Begin by picking at least three things to measure below and then download the weekly scorecard template. 

You're busy. We get it.

3 metrics we really like

Cycle Time

Cycle Time measures the time from first commit to production release. At LinearB we call this our super metric because not only does it show team efficiency, it  exposes bottlenecks in your development cycle.

Frame 887 (1)

REwork ratio

Rework ratio, also called code churn, measures the % of code being rewritten within 21 days of being merged. It’s a predictor cycle delays and downstream quality issues or could be an indication that a requirement was missed. 

Frame 888 (5)

Investment Profile

Investment profile measures how much time your team spends on different types of work. It helps you determine if you are striking the right balance between customer-facing stories, non-functional requirements and bug-fixing. 

See your team's metrics in minutes

Metrics scorecard template for your weekly staff meeting

Section 1 is for metrics we show every single week. Keeping them the same helps reinforce key messages we are trying to teach the business about how engineering works. Cycle Time is about efficiency, pickup time is about teamwork, deployment frequency is about risk and rework is about quality. 

We also show investment profile every week because the business is always interested in knowing what we’re working on and what is holding us back from investing more in new features. Our dev leaders like showing Investment Profile because it helps us justify investments in non-functional projects. 

We use section 3 to highlight different metrics that are relevant in any given week. Sometimes they stay the same for a few weeks in a row. Sometimes they change. For example, our PR review time went way up in March after work-from-home started so we monitored it here for a few weeks until it came back down.

The business will always really care about certain projects so we proactively share the most important ones in section 4. Highlighting top priorities helps align business priorities to developer work. 

We believe in sharing the bad and the ugly with the business. We use section 5 to flag projects that are behind schedule or have abnormally high risk so we can proactively communicate trade-offs. 

17 metrics to drive dev team improvement

Measuring the right indicators will help you accelerate delivery, maintain positive culture, and translate dev activity to business value. So what should modern dev leaders measure?

Keep reading to discover 17 metrics that matter for dev leaders and how to use them.

Delivery Efficiency

Efficient delivery pipelines lead to predictable value delivery, happy developers, happy product owners, and happy customers. Frustrations arise with inefficient pipelines. Measuring the stages of your delivery pipeline allows for bottleneck detection. This provides a high leverage point to increase your delivery performance because it impacts all teams and contributors

Cycle Time
Coding Time
Pickup Time
Review Time
Deploy Time
Deploy Frequency
previous arrow
next arrow
Cycle Time
Cycle Time
Definition
The amount of time from work started until work finished.
Why it matters
Cycle time is the #1 indicator of your speed to value and efficiency ratio.
Image is not available
Coding Time
Coding Time
Definition
The amount of time from work (coding) began until PR is issued.
Why it matters
This is where the magic happens. Shorter code times indicate appropriately sized chunks of deliverable work.
Image is not available
Pickup Time
Pickup Time
Definition
The amount of time it takes from the pull request submitted until review begins
Why it matters
Efficient teams have a low pickup time. The less time PRs spend waiting fo review, the faster they are released. This metric is important for all dev teams, but is even more critical for remote dev teams.
Image is not available
Review Time
Review Time
Definition
The amount of time from when the first PR comment is posted until it is merged.
Why it matters
Long reviews delay delivery and pose quality risks.
Image is not available
Deploy Time
Deploy Time
Definition
The amount of time from Pull Request Merged to Production Release
Why it matters
If time to release is high, it could mean you need to invest more in continuous deployment (CD) or that you have an opportunity to move to a micro-service architecture.
Image is not available
Deploy Frequency
Deploy Frequency
Definition
The number of times your team deploys a release per day.
Why it matters
This is a strong indicator of how much value your team is capable of getting into the hands of customers. Even if you have an efficient pipeline, if your deployment frequency is low, you may not be
delivering enough value.
Image is not available

Definition

The amount of time from work started until work finished

Why it matters

Cycle time is the #1 indicator of your speed to value and efficiency ratio.

Definition

The amount of time from work (coding) began until PR is issued.

Why it matters

This is where the magic happens. Shorter code times indicate appropriately sized chunks of deliverable work.

Definition

The amount of time it takes from the pull request submitted until review begins

Why it matters

Efficient teams have a low pickup time. The less time PRs spend waiting for review, the faster they are released. This metric is important for all dev teams, but is even more critical for remote dev teams.

Definition

The amount of time from when the first PR comment is posted until it is merged.

Why it matters

Long reviews delay delivery and pose quality risks.

Definition

The amount of time from Pull Request Merged to Production Release

Why it matters

If time to release is high, it could mean you need to invest more in continuous deployment (CD) or that you have an opportunity to move to a micro-service architecture.

Definition

The number of times your team deploys a release per day.

Why it matters

This is a strong indicator of how much value your team is capable of getting into the hands of customers. Even if you have an efficient pipeline, if your deployment frequency is low, you may not be delivering enough value.

Delivery Quality

Most teams have experienced the situation where low quality leads to missed delivery dates, iteration interruptions, long hours, unhappy customers, and a frustrated engineering organization. There are many different metrics that you could measure as an engineering leader. Some of the classics range from test coverage to service uptime. While these metrics are great, we have found that there are a few other metrics that really help to measure delivery predictability.

Rework Ratio
Refactor Ratio
Risky Branches
PRs Merged Without Review
Review Depth
previous arrow
next arrow
Rework Ratio
Rework Ratio
Definition
Percentage of recently delivered code your team is already rewriting.
Why it matters
A high rework percentage is a predictor of future quality issues. It could also happen when a feature requirement was missed, indicated a communication issue with product management or the customer.
Image is not available
Refactor Ratio
Refactor Ratio
Definition
Percentage of previously delivered (>21 days) code your team is rewriting.
Why it matters
The implication of a high refactor ratio is context dependent. You could be fixing a section of code that has created bugs, or you simply could be updating to accommodate a new feature.
Image is not available
Risky Branches
High-risk Branches
Definition
Number of branches with large changes and high rework or refactored work.
Why it matters
The general rule on most dev teams is that the larger the change, the higher the risk (i.e. branches with 300 lines of code are riskier than small branches). Branches with a high percentage of rework and refactored work are also riskier. High risk work is a leading indicator of quality.
Image is not available
PRs Merged Without Review
PRs Merged without Review
Definition
The ratio of pull requests merged without review.
Why it matters
In addition to helping understand potential quality issues, analyzing unreviewed pull requests can sometimes be an indication of a training or culture issue on a given team.
Image is not available
Review Depth
Review Depth
Definition
The average number of comments per pull request review.
Why it matters
This metric is an indication regarding the quality of the review and how thorough reviews are done. Reviews are an important factor for improving code quality and finding quality issues in code before it is merged and deployed.
Image is not available