PR size: why smaller pull requests move faster

A reviewer can hold a small change in their head. A 40-line pull request gets a real read; a 900-line one gets a skim and a “LGTM.” Small PRs have shorter pickup times (a quick review is easy to say yes to), shorter review times, fewer defects slipping through, and cleaner revert boundaries when something does go wrong.

Large PRs create the opposite spiral: they’re intimidating to pick up, so they wait; they’re hard to review well, so bugs slip; and they’re risky to merge, so they wait some more. Shrinking PR size tends to pull cycle time and time to first review down together.

DevPerform buckets each pull request by lines changed (additions + deletions) so you can see the distribution rather than a single average:

• XS — under 10 lines
• S — under 50 lines
• M — under 250 lines
• L — under 1,000 lines
• XL — 1,000 lines or more

A healthy team lives mostly in XS–M. A rising tail of L and XL pull requests is an early warning that changes aren’t being broken down — and it usually shows up in slower review turnaround a week or two later.

• Break work down before you branch. Ship a change in a sequence of reviewable slices rather than one big drop.
• Separate refactors from features. A mechanical rename mixed into a feature PR makes both harder to review; split them.
• Use stacked or incremental PRs so each layer is independently reviewable.
• Land behind flags. Feature flags let you merge small, incomplete-but-safe pieces instead of waiting to merge everything at once.

Smaller is a strong default, not an absolute law. A few caveats keep the metric honest:

• Generated code and lockfiles can make a trivial change look enormous. A one-line dependency bump that rewrites a 5,000-line lockfile is an XL by raw count but takes no real review effort — read size distributions with that in mind.
• Some changes are legitimately large — a framework migration or a vendored import can’t always be sliced. The goal is fewer needlessly large PRs, not gaming the number.
• Don’t optimize the metric into meaninglessness. Artificially splitting one logical change into ten PRs just moves the review cost around. Size is a guide toward reviewable units, not a target to hit.

This is why DevPerform reports the full bucket distribution at the team level and treats it as a heuristic, not a verdict. Benchmark a public repo to see its median PR size against industry bands.