Large pull requests are one of the most reliable predictors of slow code review cycles. PR size measures the volume of code changes in a single pull request, typically expressed as lines of code added plus lines deleted. When your squad's PRs routinely run into the hundreds or thousands of lines, review quality drops, merge times stretch, and bugs slip through. This page covers the definition of PR size, how to measure it, what good looks like, and how to bring it down.
- PR size measures the total lines of code added and deleted in a single pull request. It matters because oversized PRs slow down code review, increase the cognitive load on reviewers, and raise the probability that defects reach production undetected.
- PR size is calculated as lines added plus lines deleted in a given pull request. No universal published benchmark exists across all teams, but most engineering research and practitioner consensus points to PRs under 200 lines of changed code as a healthy target for most squads working on production codebases.
- The most common mistake teams make is conflating PR size with developer output. A player who submits ten small PRs in a week is not less productive than one who submits one large PR. Smaller PRs are a process discipline, not a productivity penalty, and treating size as a proxy for effort misreads the signal entirely.
- DevStats tracks PR size automatically by connecting to your Git provider, with benchmarks against 1,000+ engineering teams so you can see where your squad stands. Start a free trial to see your numbers in under two minutes.
PR size definition
PR size is the total number of lines of code changed in a single pull request, counting both additions and deletions. It is a process metric that reflects how work is broken down before it enters code review.
Technically: PR size = lines added + lines deleted per pull request. Some teams also track file count or commit count as supplementary signals, but lines changed is the most widely used measure. When PR size grows unchecked, it directly inflates PR cycle time, the time from PR open to merge, because reviewers spend more time per PR and often defer large reviews to find a longer focus block.
Teams that manage PR size well ship smaller batches of change more frequently, which reduces deployment risk and supports faster feedback loops across the delivery pipeline.
Why PR size matters for engineering teams
When squads do not track PR size, large PRs accumulate invisibly in the review queue. Reviewers face a choice between doing a superficial pass or blocking their schedule for hours. Both outcomes are bad: shallow reviews miss defects, and long review waits create context-switching costs that erode team productivity.
PR size connects directly to the KPIs engineering leaders care about. Slow review cycles delay sprint commitments. Defects from under-reviewed large PRs increase incident rates and eat into engineering capacity for new work. Deployment frequency, a core DORA metric, is harder to sustain when individual changes are large and risky to ship. Teams that keep PR size small tend to deploy more often and with greater confidence.
Within the SPACE framework, PR size touches the Efficiency and Flow dimension. Large PRs interrupt flow for both the author waiting on review and the reviewer pulled into a lengthy session. Measuring PR size gives you the diagnostic signal. What you do with it is your call as the engineering leader.
How to measure PR size
PR size is pulled directly from your Git provider. GitHub, GitLab, and Bitbucket all expose lines added and lines deleted per pull request through their APIs. You do not need an issue tracker or CI/CD pipeline data to calculate it, though pairing PR size with PR cycle time gives you a much richer picture of where your review process is healthy or strained.
No single published benchmark from DORA covers PR size directly. The table below reflects practitioner consensus and patterns observed across engineering teams. Benchmarks vary by codebase maturity, team size, and whether the work involves infrastructure changes, refactors, or net-new features. Use these as directional signals, not hard thresholds. You can compare your squad's distribution against peer teams using DevStats benchmarks.
| Performance level | PR size benchmark | What it signals |
|---|---|---|
| Elite | Under 100 lines changed | Work is well-scoped, reviews are fast, low deployment risk |
| High | 100–200 lines changed | Healthy decomposition, review quality generally maintained |
| Medium | 200–400 lines changed | Review thoroughness starts to degrade, cycle times stretch |
| Low | 400+ lines changed | High cognitive load on reviewers, elevated defect risk, slow merges |
PR size in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that their squad's average PR cycle time had climbed to four days over a quarter. She pulled the PR size distribution and found that 30% of merged PRs exceeded 500 lines. Those large PRs accounted for over 60% of the total review time logged by her senior players. The bottleneck was not reviewer availability. It was the size of what was being submitted.
She introduced a squad norm: any PR over 300 lines required the author to break it into a stack of smaller PRs before requesting review. She tracked the average PR size and cycle time weekly for the following six weeks. Average PR size dropped from 380 lines to 160 lines. Cycle time fell from four days to under 36 hours. She also noticed that code review comment volume per PR went up, a signal that reviewers were engaging more deeply with smaller, focused changes.
How to improve PR size
1. Set a team norm with a specific line threshold. Pick a number, for example 200 lines, and make it a visible expectation during sprint planning. Norms work better than rules when the squad understands the reasoning. Explain that smaller PRs get reviewed faster, not that large ones are penalized.
2. Introduce PR stacking for large features. When a feature genuinely requires significant code, teach players to break it into a sequence of smaller PRs that build on each other. The first PR might establish the data model; the second adds the API layer; the third adds the UI. Each is independently reviewable.
3. Separate refactoring from feature work. Mixed-purpose PRs (refactor plus new feature) are hard to review and inflate size artificially. A standing rule to keep refactors in their own PRs reduces size and makes intent clearer for reviewers.
4. Watch PR cycle time as a leading signal. If cycle time starts climbing, check PR size first. The two metrics move together. DevStats surfaces both in the same view so you can correlate them without building a manual report. You can track this directly in the PR cycle time feature.
5. Review size distribution by squad during sprint retrospectives. Aggregate data tells you the average. The distribution tells you whether one or two players are responsible for most of the large PRs, which is a coaching conversation, not a performance issue.
PR size vs. PR count
PR size and PR count are related but measure different things. A squad can have high PR count and high PR size simultaneously, which means they are shipping frequently but in large, risky batches. Tracking both together gives you a complete picture of how work flows through your delivery pipeline.
| PR size | PR count | |
|---|---|---|
| Measures | Lines of code changed per PR | Number of PRs submitted in a period |
| Starts when | PR is opened | Sprint or time window begins |
| Ends when | PR is merged or closed | Sprint or time window ends |
| Best for | Diagnosing review bottlenecks | Measuring squad throughput and delivery cadence |
Use PR size when you want to understand review quality and risk per change. Use throughput and PR count when you want to understand delivery volume over time.