Code review metrics

Code reviews are where engineering velocity goes to stall. Studies consistently show that pull requests sit waiting for review longer than they spend in any other stage of the delivery pipeline, yet most squads have no systematic way to see it. Code review metrics are the measurements that make your review process visible: how long reviews take, how often they block delivery, and how review load is distributed across your team. This page covers the definition, how to measure and benchmark these metrics, a real-world example, and how to use the data to make your review process faster without sacrificing quality.

Key takeaways

• Code review metrics are quantitative measurements of the pull request review process, including time-to-first-review, review turnaround time, PR size, and review participation rate. They matter because slow or unbalanced review processes are one of the most common hidden causes of missed sprint commitments and frustrated players.
• The most common formula is review turnaround time, calculated as the time from PR open to first review comment or approval. No single published industry benchmark covers all code review metrics, but high-performing squads typically achieve a median time-to-first-review under four hours for active working hours, with PR sizes under 200 lines of code per review.
• The most common mistake teams make is treating review volume or comment count as a quality signal. A PR with zero comments is not necessarily well-written code; it may simply be unread. Measuring participation rate alongside turnaround time gives a more complete picture of whether reviews are actually happening.
• DevStats tracks code review metrics automatically by connecting to your Git provider, surfacing review turnaround time, PR size distribution, and participation patterns across your squads, benchmarked against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.

Code review metrics definition

Code review metrics are a set of measurements that describe how pull requests move through the peer review stage of your delivery process. They capture how fast reviews happen, how large PRs are, and how consistently reviewers participate. A slow review process is one of the most direct contributors to extended PR cycle time, which in turn delays releases and compounds work in progress across the squad.

The core metrics include time-to-first-review (time from PR open to first reviewer action), review turnaround time (time from PR open to approval or merge), PR size (lines of code changed), and review participation rate (percentage of eligible reviewers who contribute). There is no single formula that covers all code review metrics, but the most actionable starting point is: Review turnaround time = timestamp of approval or merge minus timestamp of PR creation. When review times are long and PR sizes are large, the downstream effect shows up as delayed deployments, lower throughput, and compounding merge conflicts that slow the entire squad.

Why code review metrics matter for engineering teams

When squads do not track code review metrics, review bottlenecks become invisible. A team can be shipping consistently sized work items and still miss sprint commitments because PRs are queuing for 48 hours before anyone looks at them. That queue does not show up in your velocity chart or your standup. It shows up as a pattern of last-minute scrambles and late releases that nobody can explain with the data they have.

For engineering leaders, slow reviews directly affect on-time delivery and developer satisfaction. Players who submit work and wait days for feedback lose context, lose momentum, and eventually lose patience. Review load that is concentrated on one or two senior players creates a bottleneck that no amount of hiring fixes. Tracking collaboration patterns in the review process shows you whether review responsibility is genuinely shared or silently centralized. The SPACE framework identifies collaboration and flow as two of its five dimensions, and code review metrics sit squarely at the intersection of both.

Measurement is the starting point. Once an engineering leader can see where reviews are stalling and why, they can make targeted decisions about reviewer assignments, PR size norms, and review SLAs. The data surfaces the pattern; the engineering leader decides what to do about it.

How to measure code review metrics

All core code review metrics are derived from your Git provider data. GitHub, GitLab, and Bitbucket all expose the timestamps needed to calculate time-to-first-review, review turnaround time, and PR size. You do not need a CI/CD integration to get started, though pairing Git data with your issue tracker lets you connect review delays to sprint outcomes via issue cycle time.

No single authoritative benchmark exists for all code review metrics the way DORA benchmarks exist for deployment frequency. The table below reflects patterns observed across high-performing engineering organizations and is consistent with data published in the DORA State of DevOps 2023 report for related flow metrics. Benchmarks vary by team size, codebase maturity, and release model. Use them as directional signals, not hard targets. DevStats provides team-specific benchmarks based on your own historical data and peer comparisons.

For PR size, a widely cited signal from research by SmartBear and others is that PRs over 400 lines of code receive significantly less thorough reviews. Squads that keep PRs under 200 lines tend to see faster turnaround and fewer post-merge defects. Track PR size alongside turnaround time to understand whether large PRs are driving your review delays. You can see these patterns in the DevStats code review feature, which breaks down review time by squad, reviewer, and PR size band.

Code review metrics in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed her squad was consistently shipping features two to three days later than planned. Sprint velocity looked fine on paper, but release dates kept slipping. She pulled the review data and found that the median time-to-first-review was 31 hours, and 60 percent of all PRs were being reviewed by the same two senior players. The squad was not slow at writing code. It was slow at reviewing it, and the review load was silently concentrated.

She introduced two changes: a squad norm that PRs should receive a first review within four working hours, and a rotation system that distributed review assignments more evenly. She also set a soft PR size limit of 250 lines and asked players to break larger changes into stacked PRs. Over the following two sprints, she tracked review turnaround time and delivery speed side by side. Median time-to-first-review dropped to under five hours, and the two senior players reported spending less time in review and more time on high-priority work. The data told her where to look; she decided what to change.

How to improve code review metrics

1. Set an explicit review SLA and make it visible. Agree on a time-to-first-review target as a squad norm, such as four working hours. Post it in your team documentation and reference it in sprint retrospectives. Without a shared expectation, review timing defaults to whenever someone gets around to it.
2. Cap PR size at 200 to 250 lines of changed code. Large PRs take longer to review and receive less thorough feedback. Ask players to break features into smaller, independently reviewable chunks. This is a process change that pays off in both review speed and post-merge defect rates. Track PR size in your code review data to see whether the norm is holding.
3. Distribute review assignments deliberately. If two or three players are absorbing the majority of review load, rotation or assignment tooling will reduce the bottleneck. Use your activity heatmap to see where review activity is concentrated and identify players who have capacity to take on more.
4. Pair review metrics with PR cycle time. Review turnaround time is a leading indicator for overall PR cycle time. If cycle time is rising, check review lag first before assuming development is the constraint. This sequencing saves engineering leaders from solving the wrong problem.
5. Review the data in sprint retrospectives. DevStats surfaces code review patterns at the squad level. Bringing the data into your retro gives the team a shared view of where the process is working and where it is not, without singling out individuals.

Code review metrics vs. PR cycle time

Code review metrics and PR cycle time are related but measure different scopes of the pull request process. PR cycle time covers the full lifespan of a pull request from open to merge, while code review metrics focus specifically on the review stage within that window.

Use code review metrics when you want to understand what is happening inside the review stage. Use PR cycle time when you want to see how the review stage compares to other stages like coding time or time waiting for CI.