Pull request size measures the volume of code changes in each pull request, typically counted in lines of code changed. Research consistently shows that smaller pull requests lead to faster reviews, fewer bugs, and higher team throughput, making PR size one of the most actionable metrics for engineering managers.
Why Pull Request Size Matters
Pull request size has a cascading effect on nearly every other engineering metric. Large PRs take longer to review, receive less thorough reviews, introduce more bugs, and block the pipeline for longer. Google's engineering research found that review quality drops significantly for PRs exceeding 200 lines of changed code, and review time increases non-linearly with PR size.
Small PRs create a virtuous cycle. They are reviewed faster (reducing lead time), reviewed more thoroughly (reducing bugs), merged more frequently (increasing deployment frequency), and easier to roll back when issues arise (reducing MTTR). If you could improve only one engineering practice, enforcing smaller PRs would be a strong candidate for maximum impact.
From a developer experience perspective, small PRs reduce context-switching burden on reviewers, provide faster feedback to authors, and make it easier to maintain a clear narrative of changes. Large PRs, by contrast, are mentally taxing to review, often receive superficial 'LGTM' approvals, and obscure the reasoning behind individual changes.
Measuring Pull Request Size
The most common measurement is lines of code changed (additions + deletions). This is readily available from any source control platform. Track the median PR size for your team weekly and monitor the distribution. A healthy distribution has most PRs under 200-300 lines with few outliers above 500 lines.
Lines of code changed is not a perfect measure. A 200-line PR that adds a new feature is very different from a 200-line PR that refactors existing code. Some teams complement line counts with file count (how many files are touched) and cognitive complexity (how interconnected are the changes). However, line count alone is a useful starting point.
- Track lines changed (additions + deletions) as the primary PR size metric
- Monitor median and 90th percentile PR size weekly
- Count the number of files touched per PR as a secondary measure
- Exclude auto-generated files (lock files, migrations) from size calculations
- Track the percentage of PRs under your target size threshold
Pull Request Size Benchmarks
Google recommends keeping PRs under 200 lines of changed code. Many high-performing teams set a soft limit of 400 lines and a hard limit of 600 lines, above which the PR must be split. These thresholds are based on research showing that review effectiveness degrades significantly beyond these sizes.
Track the percentage of your team's PRs that fall under your target threshold. A healthy team should have 80% or more of PRs under the threshold. If less than 60% of PRs meet the target, the team needs coaching on work decomposition and incremental delivery practices.
Some types of changes naturally produce larger PRs: initial project scaffolding, large-scale refactoring, or dependency updates. Exclude these from your standard PR size analysis, or tag them separately so they do not skew your metrics. Focus your size targets on regular feature and bug fix work.
Strategies for Smaller Pull Requests
The key skill is work decomposition: breaking features into small, independently deployable increments. A feature that seems like a single PR can often be delivered as a series of PRs: data model changes first, then backend logic, then frontend updates, then integration. Each PR is small, reviewable, and independently deployable.
Feature flags enable smaller PRs by decoupling deployment from release. You can deploy partially-complete features behind a flag, keeping the code in production without exposing it to users. This allows you to merge small, incremental PRs without waiting for the entire feature to be complete.
- Decompose features into sequential, independently deployable PRs
- Use feature flags to deploy incomplete features safely
- Separate refactoring from feature work into distinct PRs
- Extract infrastructure changes (migrations, configurations) into their own PRs
- Set up automated PR size checks that flag oversized pull requests
Getting Your Team to Embrace Smaller PRs
Start by making PR size visible. Add a dashboard or regular report showing PR size distribution. When team members can see their own patterns, they naturally begin adjusting. Combine visibility with clear reasoning: explain the research linking small PRs to faster reviews, fewer bugs, and better outcomes.
Lead by example. When engineering managers and senior developers consistently submit small, well-structured PRs, it sets the standard for the team. Review your own PR size data and share it transparently. If you are asking others to keep PRs small, demonstrate that you do the same.
Address the root causes of large PRs in retrospectives. Sometimes large PRs result from unclear requirements, poor task decomposition, or technical constraints that prevent incremental delivery. Understanding why PRs are large helps you address the underlying issues rather than simply enforcing size limits.
Key Takeaways
- Pull request size has a cascading impact on review time, bug rate, lead time, and deployment frequency
- Aim for PRs under 200-400 lines of changed code, with 80% of PRs meeting this target
- Work decomposition and feature flags are the primary enablers of smaller PRs
- Review quality degrades significantly for PRs exceeding 200 lines of code
- Make PR size visible and lead by example to drive adoption of smaller PR practices
Frequently Asked Questions
- What if our architecture makes small PRs difficult?
- Architectures with tight coupling and poor modularity do make small PRs harder. This is a signal that your architecture needs attention. Invest in modularisation, clear service boundaries, and API contracts. In the meantime, use feature flags and incremental refactoring PRs to work within current constraints.
- Do small PRs create more overhead from more reviews?
- The total review time for several small PRs is typically less than for one large PR. Small PRs are reviewed faster and with less cognitive effort. The overhead of creating more PRs is minimal with good tooling and practices. The net effect is faster delivery with better quality.
- How do we handle database migrations in small PRs?
- Submit database migrations as separate, dedicated PRs before the application code that uses them. This practice, known as expand-and-contract migration, allows you to deploy schema changes independently. It also makes migrations easier to review, test, and roll back if necessary.
Explore Development Best Practices
Our Engineering Manager's Field Guide covers work decomposition, incremental delivery, and other practices that enable smaller PRs.
Learn More