Code review velocity

Code review velocity is the time it takes for a pull request to receive a completed review after being opened. A review is considered complete when the final approver marks it as approved, or when the review process concludes with an actionable outcome (approved, changes requested, or rejected).

The metric matters because code review is one of the largest sources of wait time in modern software development. A developer who finishes coding a feature in four hours may then wait two days for a review. During that wait, the developer starts other work and loses the mental context of the original feature. When review feedback finally arrives, switching back to address comments takes longer and produces lower-quality responses than if the feedback had come within hours.

Code review velocity is distinct from review thoroughness. Speed without quality is counterproductive. The goal is not to rush reviews but to reduce the idle time between when a review is requested and when a reviewer begins. Most of the delay in code reviews is not the time spent reading code; it is the time the pull request spends waiting in a queue.

Teams typically track code review velocity as a median or percentile rather than an average, because a small number of very slow reviews (complex changes, holiday periods, understaffed teams) can skew the mean. The p50 tells you what typical looks like, while the p90 reveals how bad it gets for the slow tail.

Breaking code review velocity into its components reveals where the time actually goes and which interventions will have the greatest effect.

In most teams, queue time dominates. The pull request sits idle waiting for a reviewer to pick it up. Active review time is typically measured in minutes, not days. Iteration cycles add time when the initial review requests significant changes and the author must rework and resubmit.

Connecting code review velocity to lead time for changes and deployment frequency shows the downstream impact. A team with a two-day median review time cannot deploy faster than every two days, regardless of how quickly they write code. Review velocity often sets the ceiling on overall delivery speed.

Research from the DORA programme and industry surveys consistently finds that elite-performing teams complete reviews within hours. The gap between elite and average is not about review quality; it is about prioritisation and process design. Teams that treat reviews as interruptions will always be slower than teams that treat reviews as first-class work.

1. 1

   Keep pull requests small

   Small PRs (under 400 lines of change) are faster to review, produce better feedback, and have fewer iteration cycles. A reviewer can complete a small PR in 15 to 30 minutes, making it easy to fit into the flow of the day. Large PRs create a psychological barrier that causes reviewers to procrastinate.

2. 2

   Establish review SLAs

   Set a team expectation for initial review response time, such as four working hours. Making the expectation explicit and visible changes behaviour. Track adherence to the SLA as part of the team's process health metrics.

3. 3

   Automate what machines can check

   Linting, formatting, type checking, and test execution should happen in CI before a human reviewer sees the PR. When reviewers spend time on issues that a linter could have caught, both velocity and morale suffer. Automated checks free reviewers to focus on design, logic, and correctness.

4. 4

   Rotate and distribute review load

   Concentrated review responsibilities create bottlenecks. If one senior engineer reviews all PRs, their availability becomes the constraint. Distribute review responsibilities across the team, pair junior reviewers with seniors for learning, and use automated assignment tools to balance load.

5. 5

   Block dedicated review time

   Some teams find success with dedicated review windows, such as the first 30 minutes of each morning. This creates a predictable rhythm where authors know when to expect feedback and reviewers can batch their review work without constant context switching.

KPI Tree lets you model code review velocity as part of a broader engineering delivery tree, connecting review speed to its upstream causes and downstream effects. The tree can segment review velocity by team, repository, reviewer, and PR size to pinpoint where bottlenecks concentrate.

Linking review velocity to cycle time, lead time for changes, and deployment frequency creates a complete delivery pipeline view. When review velocity degrades, you can trace the impact through to deployment delays and quantify the cost of slow reviews in terms of delayed value delivery.

Each team can own their review velocity node and set improvement targets. Over time, the tree builds a record of whether process changes, such as smaller PR sizes or dedicated review windows, are actually moving the metric.