Compare team code review: who's actually getting a second pair of eyes
This one lives only on the Comparison view — pick two or more boards and it draws one peer-approval-coverage line per board, plus a scorecard that lines every team up side by side. It's built to answer one question a CTO asks in every skip-level: which of my teams is quietly merging without review, and which one has actually got this figured out.
| Board | Coverage | PR-open time | Comment rate | Ticket-linked | Merged PRs |
|---|---|---|---|---|---|
| Payments | 96% | 0.6d | 4.1/PR | 91% | 142 |
| Growth | 78% | 1.2d | 2.3/PR | 74% | 203 |
| Platform | 52% | 1.9d | 1.4/PR | 60% | 88 |
Peer-approval coverage, three boards, plus the team scorecard.
Merged-PR volume greyed — this board set mixes GitHub and Azure DevOps, so raw counts aren't comparable.
What it measures, and where the data comes from
Two views of the same underlying data. The line is peer-approval-coverage percentage — the share of merged pull/merge requests that got at least one real approval from someone other than the author — plotted per board, per week. The scorecard underneath adds four more columns: median PR-open time, comment rate (comments per PR), ticket-linking rate, and merged-PR volume.
- GitHub — pull requests: approving reviews and comment counts, per connected repo.
- Azure DevOps — pull requests, same approval and comment signals, from repos opted into code intel.
Higher is better on every column except PR-open time. The catch is the last one: merged-PR volume is a raw count, and raw counts don't mean the same thing on a GitHub board as they do on an ADO board — different PR-splitting conventions, different repo structures. Whenever the boards you've selected mix providers, Deckgauge greys that cell out rather than let you eyeball two numbers that were never meant to be compared.
How to read it
Look at the lines before the table. Whichever board's coverage line sits lowest, consistently, over several weeks — that's the team merging without a second pair of eyes more often than its peers. Then check the table for the "why": is comment rate also low on that same board? That usually means reviews are either skipped entirely or rubber-stamped, and those need different fixes.
Don't let a high coverage number alone convince you a team's review culture is healthy. A board can hit 95% coverage with a comment rate near zero — reviewers clicking approve without reading. Coverage tells you approval happened; comment rate tells you whether anyone engaged with the diff.
What it tells you over time
A coverage line that holds steady near the top of the pack, quarter over quarter, is the strongest signal you'll get that a team's review culture is durable rather than a one-off good sprint. Use that board as your reference point when another team's line starts sliding — not as a lecture, but as a concrete "here's what normal looks like."
Example situations
1. One team is merging without review, and it's been true for a month
Platform's coverage line sitting well under the other two boards.
What you're seeing: Payments and Growth are both holding coverage in the 90s, while Platform's line has been sinking for six straight weeks and is now under 50%. Half of Platform's merges are landing with nobody else's name on them.
How to react: don't open with a policy memo about "mandatory review." Go look at why — is Platform short a reviewer after someone left? Is the team small enough that everyone's slammed and approvals feel like a tax? The scorecard's PR-open time column tells you if PRs are even getting looked at before they merge, or bypassed outright.
2. A greyed cell almost gets read as a real comparison
| Board | Coverage | Merged PRs |
|---|---|---|
| Payments (GitHub) | 91% | 310 |
| Infra (ADO) | 84% | 64 |
Merged-PR volume greyed across a GitHub + ADO board set.
What you're seeing: Payments shows 310 merged PRs against Infra's 64, and it's tempting to read that as "Payments ships nearly five times the changes." The cell is greyed for exactly this reason — Payments is on GitHub, Infra is on Azure DevOps, and the two tools don't split work into pull requests the same way.
How to react: don't compare the raw counts across the tool boundary. If you need to know which team is delivering more, use a Compare: Flow or Compare: Delivery board that's normalized on rate or duration instead — this widget's job is review discipline, not throughput.
Frequently asked
- How do I compare code review discipline across teams?
- The Comparison view draws one peer-approval-coverage line per board plus a scorecard lining every team up side by side, which answers whether a given team is merging without a genuine second pair of eyes.
- What is peer-approval coverage?
- The share of merged pull or merge requests that received a genuine approval from someone other than the author. It is the single clearest indicator of whether review is real or ceremonial.
- Why does merged-PR volume grey out when providers mix?
- Because pull request semantics differ between providers, so a combined volume figure across mixed boards would not mean anything. The coverage percentage stays comparable and is what the view is for.
Related widgets
- Review Quality Index — the single-board version of this same coverage signal.
- Compare: Flow — cycle time across the same boards, for the "are they slow because reviews are thin" question.
- Compare: Delivery — normalized delivery volume across boards, for the throughput half of the story.
- Back to the widget reference.
Last updated