Deploy free

Ideal pull request size: the habit hiding behind every slow review queue

PR Size Distribution buckets every merged PR into XS, S, M, L, or XL by lines changed, coloured by tier — Elite under 250 lines, High under 500, Medium under 1,000. The ideal pull request size is smaller than most teams think: small PRs review faster, merge sooner, and break less. It's pulled from GitHub, GitLab, and Azure DevOps. If your review queue feels slow and nobody can say why, this chart is usually where the answer is hiding.

deckgauge · Board · Intelligence
XS
S
M
L
XL

A healthy shape — mass sitting in XS/S, a short tail.

What it measures, and where the data comes from

Every merged PR gets bucketed by lines changed, then coloured to match the size band it falls in: XS and S sit inside the Elite band, M is High, L is Medium, and XL is what's left over once a change has outgrown all three. The bars are a count of merged PRs per bucket over the selected window — read the shape, not any single bar.

  • GitHub — lines added plus lines deleted across every file in the merged pull request, from the GitHub diff stats.
  • GitLab — the same additions-plus-deletions total, taken from the merged merge request's diff.
  • Azure DevOps — line changes from the completed pull request's iteration diff.

Generated files, lockfiles, and vendored code inflate this number if your repo doesn't gitignore or diff-exclude them — a one-line dependency bump that drags in a 4,000-line lockfile diff will land in XL and lie to you. Worth checking once, then forgetting about.

How to read it

Look at where the mass sits, not the tallest bar. A distribution stacked left — most PRs in XS and S, a thin M, almost nothing past that — means the team has internalised small batches as the default way of working. That's the shape you want, and it's rarer than it should be.

A distribution stacked right, or bimodal — a big pile of tiny PRs plus a separate cluster of L/XL ones — is the more common failure mode. It usually means small PRs are a policy on paper and a habit for some engineers, while a few big features (or a few specific people) still land as one giant diff. The bimodal shape is easy to miss if you only glance at the average.

What it tells you over time

Two things move this histogram: a genuine shift in how the team ships, and a single oversized migration that happened to land this sprint. Watch whether mass is migrating left (toward XS/S) or right (toward L/XL) release over release. A push toward smaller PRs — a new template, a stated norm, a linter that nags at 400 lines — should show up here within two or three sprints as bars visibly moving left. If it doesn't, the policy isn't sticking, whatever people say in standup.

Example situations

1. A fat L/XL tail clogging the review queue

deckgauge · PR Size Distribution
XS
S
M
L
XL

Mass has shifted right — big batches dominate.

What you're seeing: the tallest bars are L and XL, not XS and S. Most merged work is arriving as big batches — the review queue isn't slow because reviewers are lazy, it's slow because what lands in it takes hours to read properly.

How to react: cross-check this against Review Pickup Time and PR Cycle Time before you conclude anything — a fat tail here usually explains a slow number on both of those. Then look at where the big PRs are coming from: one feature area, one project, or a specific handful of authors. It's rarely "the whole team decided to go big" — it's usually a pattern with a source.

Managerial playDefault to small: make "<400 lines" the norm the team owns, not a rule you enforce after the fact — a soft nag from a bot at 400 and a hard flag at 600 works better than a lecture. Split by design up front, not after the diff is already huge — plan features as a sequence of mergeable slices before anyone opens an editor. And make the small path the easy path: PR templates that assume one concern per PR, and stacked-PR tooling (GitHub's native stacks, Graphite, or similar) so splitting a big change doesn't feel like extra process overhead.

2. Mass migrating left, sprint over sprint

deckgauge · PR Size Distribution
XS
S
M
L
XL

Same team, twelve weeks later.

What you're seeing: compared to a few sprints back, XS and S now dominate and the L/XL tail has all but disappeared. This is the shape after a genuine push for smaller PRs — not a fluke week, a sustained shift.

How to react: this is a win, and it's an easy one to let go unnoticed because nothing broke. Don't just quietly note it and move on.

Managerial playCelebrate it out loud — in the retro, in the update to your own boss, by name if a specific person championed the norm. Then keep the norm alive on purpose: revisit it whenever a new hire joins or a big migration project starts, both of which quietly pull teams back toward giant PRs. A win like this decays if nobody's watching it; a chart like this is how you notice before it slides back.

Frequently asked

What is the ideal pull request size?
Smaller than most teams assume. The widget buckets merged pull requests into XS, S, M, L and XL by lines changed and colours them by tier — Elite under 250 lines, High under 500, Medium under 1,000. Small pull requests review faster, merge sooner and break less.
How do I read the PR size distribution?
Look at where the mass sits rather than at the tallest bar. Stacked left, into XS and S, means small batches are the team's default. Stacked right or bimodal usually means small pull requests are a policy on paper while some work still lands as one giant diff.
Why do lockfiles and generated code distort this?
Because line counts include them. A one-line dependency bump that drags in a 4,000-line lockfile diff lands in XL and misrepresents the change. Excluding generated files from diffs fixes it once.

Related widgets

Last updated