How to Shrink change batch size
Small changes are easier to review, test, release, and reverse. This guide shows you how to split work before coding, stop oversized pull requests from merging, integrate unfinished work daily, use feature flags to separate deployment from exposure, and set a team standard that keeps batch size small under pressure.
Developing
Start here. Build the foundation.- 1
Before starting work that spans many files or concerns, divide it into pieces that each deliver something on their own. Use a one-sentence test: if you cannot describe one piece clearly in a sentence, split it again. You have it when each change can be reviewed and shipped the same day instead of waiting for the whole feature.
- 2
When a pull request exceeds the team's size limit or bundles unrelated changes, flag it and propose where to split it before approval. Do not wave it through because careful review feels expensive. The signal is that the request returns as smaller, focused changes a reviewer can reason about confidently.
Proficient
Build consistency and rhythm.- 3
When an active branch approaches one working day old, merge its safe progress into the shared main line. If unfinished behavior cannot be exposed, reduce its scope or use a feature flag. You are doing this well when no personal branch goes more than a day without integrating and merge conflicts stay small.
- 4
When a risky change cannot be divided further, put it behind a feature flag and deploy it switched off. Define who can turn it on and which signal will stop the rollout before merging. The signal is that code reaches production safely while exposing the behavior remains a separate, reversible decision.
Mastered
Operate at the highest level.- 5
When large changes recur, write an explicit team standard such as a pull request size target or maximum branch age, and reference it in planning and review. Revisit the limit when it stops fitting, adjusting it instead of abandoning it. Mastery shows when teammates use the standard without prompting and split work before review.
Common Pitfalls
Avoid the common failure modes.- Waiting until review to split work. By then, the design and code are already bundled. Break the change into independently shippable units before implementation starts.
- Keeping a branch alive until the full feature is finished. Long-lived branches hide integration problems and create painful merges. Integrate safe progress daily and hide incomplete behavior behind a flag when needed.
- Approving an oversized pull request because reviewing it properly feels like too much effort. That effort is a warning about batch size. Send it back with a concrete split instead of accepting hidden risk.