Set a team norm of prioritizing code reviews
To limit work in progress and make a small-PR workflow possible, set a team norm of prioritizing code reviews over other tasks.
When teams commit to keeping pull requests small and manageable, it becomes possible to review and merge changes quickly. However, this approach only works if reviews are prioritized and completed promptly. If reviews are delayed, even small PRs can pile up, leading to increased work in progress (WIP), blocked work, and long feedback loops.
To make a small-PR workflow effective, we establish a norm of prioritizing code reviews over other tasks. This can mean different things to different team members, but might involve:
- Don't pick up new work until you've reviewed any pending PRs assigned to you.
- If you're waiting on reviews for your own PRs, use that time to help review others' PRs.
- Be responsive to review requests from others in Slack or Teams.
- Any time you're switching contexts, check for pending PRs that need your attention.
- Allow specific kinds of PRs (e.g., documentation updates, small bug fixes) to be merged with minimal or no review, so long as they meet quality standards. This becomes more feasible when the CI/CD pipeline has strong automated checks in place.
By setting these norms, we create a culture where reviews are seen as a critical part of the development process, rather than an afterthought. This helps keep WIP low, reduces the risk of merge conflicts, and ensures that changes are delivered to production quickly and safely.
Help us improve
Your feedback helps us create better resources for teams like yours.
Related Plays
Last updated on