top of page

Tutorial 10: Measure Review Health

  • Contributor
  • 4 days ago
  • 3 min read

Reviews can become a bottleneck or a strength. Numbers tell you which.

Step 1: Pick Useful Metrics (10 min)

Good signals:

  • Cycle time — open to merge

  • First-response time — open to first review comment

  • Review depth — comments per PR; weighted by severity

  • Stuck PR count — open > N days

  • Rework count — pushes after first approval

Bad signals:

  • Comments per PR alone — encourages bikeshed

  • Approval count — encourages rubber stamps

  • PR size — encourages tiny non-features

Pick metrics tied to outcomes.

Step 2: Cycle Time (10 min)

Target:

  • Small PRs (< 100 lines): < 24h

  • Medium PRs (100-300): < 48h

  • Large PRs (300+): < 1 week

If your median cycle time is 5 days for small PRs: review is bottlenecked.

Step 3: First-Response Time (10 min)

How long until any human responds?

Target: < 4 hours during business hours.

Slow first response = author stalls and context-switches. Productivity tank.

Solutions: better notifications, oncall reviewer rotation, async-friendly culture.

Step 4: Review Depth (10 min)

Approvals on huge PRs with no comments = red flag.

Tracked through:

  • Comments per 100 lines of code

  • Time spent in review (some tools track)

  • Substantive comments vs. nits

Manual review of recent PRs every quarter: are reviews actually thorough?

Step 5: Stuck PRs (10 min)

PRs open > 7 days
PRs with unresolved comments > 5 days
PRs awaiting review > 3 days

Track and act:

  • Surface in team standup

  • Auto-tag stuck PRs

  • Rotate reviewers if original isn't responding

Stuck PRs accumulate. They cost author motivation.

Step 6: Tools (10 min)

  • GitPrime / LinearB / Pluralsight Flow — full analytics

  • Sleuth / Swarmia / Code Climate Velocity — DORA + review metrics

  • Custom dashboards — query GitHub API

Free option: GitHub's "Insights" tab has basic data.

For larger orgs: paid tools pay for themselves in finding bottlenecks.

Step 7: Don't Game Metrics (10 min)

Bad pattern:

  • "Cycle time is high" → reviewers rubber-stamp to speed up

  • "Comment count is low" → reviewers add nits to inflate

Measure outcomes, not activity. Quality + speed; not one at the cost of the other.

Step 8: Survey the Team (10 min)

Numbers don't capture everything. Ask:

  • Do you feel reviewed PRs improve in quality?

  • Are reviews tolerable in time and tone?

  • Do you trust the review process?

Anonymous survey. Quarterly.

Numbers + sentiment = real picture.

Step 9: Iterate on Process (10 min)

Quarterly retro:

  • What's slowing reviews?

  • Where are juniors stuck?

  • What conventions need updating?

Test changes:

  • Pair reviewing for big PRs

  • Async stand-up note about review queue

  • Mandatory oncall reviewer role

Measure impact. Keep what works.

Step 10: Tie to DORA Metrics (5 min)

DevOps Research and Assessment metrics:

  • Lead time — commit to prod (includes review)

  • Deploy frequency — how often you ship

  • Change failure rate — % of deploys causing problems

  • MTTR — mean time to restore

Slow review = slow lead time. Track DORA; review health is part of it.

What You Just Did

Review metrics: cycle time, first response, depth, stuck PRs, tools, anti-gaming, surveys, iteration, DORA. Reviews as a measurable practice.

Common Failure Modes

Track metrics; never act. Numbers in a vacuum.

Game the metric. Cycle time drops; quality suffers.

No surveying. Quantitative-only; miss culture issues.

One-time measurement. Drift between checks.

Review metrics in isolation. Disconnect from outcomes (DORA, quality).

You're Done With Path 39

Code reviews that help: reviewable PRs, prioritization, feedback, large PRs, security, readability, conventions, disagreement, juniors, metrics. Reviews as a practice.

Recommend Technical Writing for Engineers — pair clearer code with clearer writing.

bottom of page