Pull request frequency measures the number of pull requests merged into the default branch per developer each day. It provides insight into your organization’s development velocity and continuous integration practices.
High-performing development teams most often practice continuous integration and trunk-based development, the process of merging small and frequent code changes into a single branch. When using this development flow, high-performing teams can integrate new code hundreds or thousands of times per day. Most developers will commit to the mainline everyday, which means most developers will merge at least one pull request every day.
Some engineering teams instead rely on feature branches, a development process that involves long-lived branches containing specific features, which teams merge to the mainline when they are fully completed. When using feature branches, pull request frequency can serve as an additional proxy for new features shipped.
Understanding pull request frequency
High pull request frequency indicates an organization's ability to review, merge, and integrate new changes into the codebase. High-performing teams enable the fast flow of work, providing development teams with the tools and practices they need to get their work done.
For many engineering teams, low pull request frequency indicates either friction when integrating changes (i.e. closing pull requests) or friction earlier in the delivery pipeline (i.e. opening pull requests).
Decrease batch size
Batch size measures the size of each unit of work. Large batches of work can be more difficult to integrate because they are more complex to review, test, and approve. They can lead to costly merge conflicts and often require additional developer resources to move them to the next phase in the delivery pipeline.
Small batches of work are easier for reviewers to inspect and approve. When integrated frequently, small batches are less likely to cause merge conflicts and are simpler to debug or revert if they cause issues.
Decrease review time
Decreases in pull request frequency can indicate a backlog of review requests. Teams may have too few team members reviewing code, insufficient automated testing to decrease manual labor, or a lack of communication when pull requests are ready for review.
It’s important to balance review time with code quality, test coverage, and failure rate. Teams can increase pull request frequency by merging changes without any code review process, but these teams may see a reduction in product quality.
Shift left or right on code reviews
If pull request reviews are creating bottlenecks in the delivery pipeline, teams can try reviewing code earlier in the development process. One strategy to review code earlier is known as continuous review, when teams review code as it's written, often through pair programming.
Shifting right on code reviews means teams continuously revisit and fix old code. Martin Fowler introduced a process known as refinement code reviews, where teams embrace a more fluid and perpetually changing codebase. According to Fowler:
This process of refinement is exactly the same as what happens in a code review, but it's triggered each time the code is looked at rather than when the code is added to the codebase.
Decrease merge time
Time-consuming and burdensome change approval workflows can create backlogs of pull requests and decrease pull request frequency.
Teams can introduce lightweight change approval processes that don’t require input from change advisory boards (CAB) or senior managers. They can also shift left on testing and security to avoid bottlenecks during the pull request phase by resolving security issues and improving code quality earlier in the pipeline.
Improve daily work
Pull request frequency can also be the result of friction early in the development pipeline. In this scenario, teams are unable to easily complete their work due to inefficient workflows, tools, and practices.
Teams should improve daily work to improve the flow of work from code to pull requests.
- Reduce interruptions and context switching. Context switching can be caused by high meeting load, frequent firefighting, too much work in progress, and more. If teams are unable to get their work done, changes in pull request frequency can be an early warning sign of developer burnout.
- Reduce handoffs and wait time. More efficient workflows avoid delays caused by frequent handoffs or slow tooling. They can also improve code quality and decrease review time by providing faster feedback to developers before opening pull requests. Teams should invest in automations that help developers get their work done, such as self-service environments, faster test data, and better testing tools.
- Dedicate time for the improvement of daily work. Teams should set aside time and resources each development cycle to improve their organization’s developer experience. They can automate workflows, refactor code, or pay down technical debt.
Measuring pull request frequency
With small units of work, automated workflows, consistent reviews, and a culture of continuous integration, teams can use pull requests to achieve stronger DevOps performance in their organization.
To measure pull request frequency, teams can install the Software GitHub app for their organization.
