Set a pull request size limit for an offshore delivery team

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Measure the review load, not just lines

A pull request limit should reflect the work a reviewer must hold in their head. Count changed files, touched systems, and the number of behaviors that need a check. A small diff that changes authentication can be harder to review than a large documentation update. Set separate limits for high-risk and low-risk changes. The limit should make the review smaller, not encourage arbitrary splitting.

Collect a month of review data before choosing a number. Record the review time, the number of comments, and the defects found after merge for each change. Look for the point where review time rises faster than the change size. That point is a better guide than a round number borrowed from another team. Publish the baseline so the team can see why the limit exists.

Set a limit with a clear exception path

Write the default limit as a range, such as one behavior and a small number of files per pull request. Name the reviewer who can approve an exception and the reason that justifies one. A migration, a generated lockfile, or a mechanical rename may need a larger diff. Record the exception in the pull request description. An exception without a reason becomes the new default.

Do not use a line count as the only rule. A generated file can add thousands of lines without adding review risk. A ten-line change to a payment path can carry more risk than a large test update. Apply the limit to the reviewable behavior and list the generated files separately. The reviewer should know which part of the diff needs attention.

Split work by behavior and risk

Split a large change along the behavior a reviewer can test, not by file count. A database migration, an API change, and a user-interface update are separate review units even when they ship together. Use a feature flag or a stacked branch to keep each part reviewable. The series should tell a story from the data change to the customer result. Each pull request should stand on its own.

Plan the split before coding starts. If the team discovers a second behavior halfway through, stop and create a follow-up branch. Do not hide a refactor inside a feature change to avoid a second review. Refactors that make the next change easier can be reviewed on their own. A clean series is easier to revert than one large commit.

Require a review packet with every branch

Every pull request should include a short packet: the problem, the approach, the test evidence, the risk, and the rollback. Link the ticket and the design note. State what the author did not verify. A reviewer who has to reconstruct the context from the diff will miss the same thing twice. The packet should fit on one screen.

Ask the author to list the exact commands a reviewer can run. Include the environment and any data the check needs. If a test cannot run in review, say why and name the evidence that stands in for it. Record the reviewer and the time the review started. The packet is part of the change, not optional paperwork.

Track rework and review wait

Measure the time from review request to the first substantive comment. Measure the time from approval to merge. Track how often a change returns for a second review round. A size limit that lowers review time but raises rework has not helped. Read the three measures together before changing the rule.

Segment the data by risk tier and by reviewer. A high-risk queue that waits for one specialist may need a backup reviewer rather than a smaller diff. A low-risk queue that still takes days may have a notification problem. Record one change and the date the team will check its effect. Keep the definitions stable between reviews.

Review the limit each quarter

A pull request limit is a hypothesis about how the team reviews best. Revisit it each quarter with the review data and a sample of recent changes. Ask reviewers whether the limit helped them find defects or only added branching overhead. Ask authors whether the split made the work clearer. Change one variable at a time, then measure again.

Retire the rule if it no longer matches the work. A team that moves from a monolith to small services may need a different limit. A team that adds a security reviewer may need a lower threshold for risky changes. Write the new rule and the reason in the engineering guide. The goal is a review the team can complete well, not a number that looks disciplined.

Handle urgent fixes without breaking the rule

A production incident may need a change that cannot wait for the normal split. Create a hotfix path with a named approver, a narrow scope, and a required follow-up review. The hotfix should restore the service, not clean up the surrounding code. Record the exception and the time it was approved. After recovery, review the hotfix like any other change.

Do not let the hotfix path become the way the team avoids review. Track how often it is used and for what reason. A rising count may mean the normal review is too slow, not that the team is careless. Fix the review queue or the notification path before tightening the exception rule. The exception exists to protect customers, and it needs the same evidence standard.

Frequently asked questions

Sources

1. NIST Secure Software Development Framework

   Review and evidence expectations referenced here.

2. GitHub Docs, about pull request reviews

   Review mechanics used in the packet.

3. Google Technical Writing courses

   Guidance for the written review packet.