Unlocking Efficiency: Optimizing Pull Request Reviews for Enterprise Engineering Teams

To deliver innovative products and experiences, engineering teams must work efficiently without compromising quality. Over the years, the software development lifecycle (SDLC) has evolved to include code reviews to ensure this balance. But, as engineering teams grow, so can the complexity of the review process. From understanding industry benchmarks to improving alignment across teams, this article outlines strategies that large engineering organizations can use to optimize Review Cycles.

Understanding Pull Request Review Cycles

The Review Cycles metric measures the number of times a Pull Request (PR) goes back and forth between an author and a reviewer. The PR review process is an essential component of PR Cycle Time, which measures the time from when the first commit in a PR is authored to when it’s merged. Leaders use this data to understand how long it takes to deliver innovation and establish baseline productivity for engineering teams.

Consider a PR for a new feature. Before the PR gets merged, it must be reviewed by a member of the team. If the PR gets approved and merged in a single cycle with no further interaction from the author, then the Review Cycle count is one. If the PR is not approved and requires changes, then the author must make an additional commit. The reviewer then checks the new version before it’s approved. In this scenario, the number of Review Cycles is two. This number increases as the PR is passed back and forth between the author and the reviewer.

By evaluating engineering metrics across enterprise companies, Code Climate identified a pattern in high-performing teams. Research found that the top 25% of organizations have an average of 1.1 Review Cycles, whereas the industry average is 1.2 cycles. When Review Cycles surpass 1.5, it’s time to investigate why.

What Causes a High Number of Review Cycle?

A high number of Review Cycles in engineering might stem from a combination of challenges that hinder the efficiency of the process. These include differing interpretations of what constitutes "done," misalignment between the expected changes and the actual changes resulting from the review, or conflicting views on the best approach to implement a solution. If there are anomalies where Review Cycles are high for a particular submitter, it could indicate they’re struggling with the codebase or aren’t clear about the requirements. This presents an opportunity for leadership to provide individualized coaching to help the submitter improve the quality of their code.

The first step in addressing a high number of Review Cycles is to identify the reason PRs are being passed back and forth, which requires both quantitative and qualitative information. By looking at Review Cycles alongside other PR metrics, leaders can look for correlations. For example, Review Cycles tend to be high when PR Size is high. If this is true in your organization, it might be necessary to re-emphasize coding best practices and encourage keeping PRs small.

Leaders might also want to do a closer review of PR data to understand which PRs have the highest Review Cycles. They can bring this information to the teams working on those PRs to uncover what exactly is causing the PRs to bounce around in review. Maybe there’s a misalignment that can be worked through, or requirements are shifting while the project is in progress. Leaders can work with teams to find solutions to limit the number of times PRs are volleyed back and forth by establishing expectations for reviews, how solutions should be implemented, and when a review is complete. Best practices for the PR review process should be documented and referenced by all team members.

Optimizing Pull Request Reviews to Meet Business Goals

For large engineering organizations, paying attention to Review Cycles is essential. Keeping Review Cycles low can boost efficiency, productivity, and innovation by minimizing delays and facilitating swift project progression. In addition, when Review Cycles are high, it can be a signal of a bigger issue that needs to be addressed, like a misalignment within a team, or a failure to maintain best practices.