The Goldilocks Pull Request
Not Too Big, Not Too Small
If you’ve ever reviewed a pull request that made changes to 47 files, touched seven unrelated features, and had a commit message like “misc fixes,” you know the pain of a PR that’s just too big. On the other hand, opening a PR that changes one line of code and doesn't even complete a feature can be equally frustrating for reviewers trying to understand the context. So what's the right size for a pull request?
Like Goldilocks searching for the perfect bowl of porridge, we’re all looking for PRs that are just right: not too big, and not too small.
Goldilocks and her pull request: not too big, not too small.
A PR Should Tell One Story
The most important rule of thumb is this: a pull request should be focused. It should do one thing well: fix a bug, add a feature, or refactor a specific part of the code.
This helps everyone:
Reviewers can follow what changed and why, without jumping between mental contexts.
CI tools can test exactly what was touched.
Your future self can read the commit history and understand the codebase's evolution.
In other words, a good PR is like a short story. It has a beginning, a middle, and an end. It shouldn’t try to be a novel.
But What If the Story Isn't Finished?
Sometimes, especially when building large features, it’s tempting to wait until everything is perfect before opening a PR. Don’t. This is where agile thinking helps.
Agile encourages incremental delivery, not just of software to customers, but also of work to your teammates. In fact, one of the core ideas behind Agile is reducing batch size: break big things into smaller pieces, deliver them quickly, get feedback, and improve.
So yes, it’s OK to open a PR that covers only part of a feature—as long as it does something complete and testable. Maybe it adds a new UI component, but doesn’t yet hook it up to the backend. That’s fine. Just be clear in your description about what’s included and what isn’t.
What DevOps and Toyota Can Teach Us
One of the unsung influences on Agile and DevOps is the Toyota Production System, which introduced the idea of flow efficiency. The basic premise: it’s better to keep work moving steadily through the system than to have big batches waiting around for review or approval.
Huge PRs slow everything down. They’re harder to review, harder to test, and more likely to cause merge conflicts. Worse, they delay feedback. If it takes two days to review your code, you’ve probably already moved on mentally to a different task. That makes responding to review comments slower and more error-prone.
In contrast, small, focused PRs keep the team moving. Reviewers can scan the changes quickly. Automated tests run faster. The chance of merge conflicts goes down. And if something breaks, it’s easier to pinpoint the cause.
Who’s Doing the Reviewing?
Another thing to consider is who will review your PR. If it’s someone deeply familiar with the codebase, they might be able to handle a slightly larger change. But if you’re asking a newer team member or someone from a different part of the org, smaller is better. You’re making it easier for them to help you.
Tools like GitHub’s code owners can help automatically assign the right reviewers. And if you’re using a DevOps platform that includes review automation, make sure it can flag PRs that are unusually large or touch too many files. That’s a good sign you need to break things up.
A Quick PR Checklist
Before you hit “Create pull request,” ask yourself:
Does this PR do one clear thing?
Is it the smallest possible unit of work that’s still meaningful and testable?
Is the description clear about what’s included and what isn’t?
Will a reviewer be able to review this in one sitting (ideally 15–30 minutes)?
If the answer is yes, congratulations! You’ve hit the Goldilocks zone.
Final Thought: It’s Not About Perfection
There’s no single right size for a PR. Sometimes you’ll need to ship a bigger one because of how the code is structured or because of timing. That’s OK. But the goal should always be clarity, focus, and flow. And if your team agrees on what a “good” PR looks like, you’ll move faster together.
Want to get better at working with pull requests, DevOps practices, and team collaboration? Open a free Caparra account. You’ll get access to powerful tools designed to help you build faster, review smarter, and reduce toil in your workflow. Start building with Caparra today:
