Pull Request Statistics: What, Why and How to Find in Bitbucket Data Center

[#1]

By tracking and analyzing pull request statistics, engineering managers and their teams can gain valuable insights into their development workflow, code quality, collaboration efficiency, and performance. This article will explore what metrics to measure and why and how to find them in Bitbucket.

Pull Request Metrics to Measure

Pull request statistics encompass a variety of metrics that offer insights into the development process, helping engineering managers to:

• evaluate teams performance
• ensure adherence to coding standards, and minimize technical debt
• identify potential issues early and find bottlenecks in workflow
• increase efficiency and reduce time to market.

Here are suggestions of what to measure.

Number of PRs

Monitoring the number of created, merged, and declined PRs and their ratio showcases team activity, workload distribution, quality of developed code, and review efficiency. Here also comes the number of PRs merged without reviewers, as code without checking could lead to bugs, vulnerabilities, or deviations from coding standards, impacting the overall quality of the software.

PR Size

Analyzing the number of lines of code or file changes in a pull request helps mitigate potential risks associated with the code review process. It's known that large pull requests often tend to be merged faster by developers, as understanding the planned changes requires a lot of effort in this case. This may lead to potential bugs, vulnerabilities, or inconsistency with internal standards. However, it's essential to balance PR size to avoid fragmentation of code into too small parts, making it difficult to get the overall picture of the planned changes and their logic.

PR Cycle Time

PR Cycle Time measures the duration from creating a PR to its resolution. Tracking this metric provides insights into how quickly code changes are reviewed, approved, and merged. A shorter cycle time generally indicates a more efficient development process, but exceptions may exist. For example, a very short cycle time may mean code review just for the record.

To find bottlenecks and inefficiencies, it’s also helpful to look at cycle time four phases:

• Time to Open. Reflects how quickly developers initiate the process of code review.
• Pickup Time. Indicates the availability of reviewers to start checking and the efficiency of communication between team members.
• Review Time. Provides insights into how fast feedback is provided, changes are made, and agreements are reached.
• Time to Deploy. Shows how quickly changes are delivered to end users.

Depending on how the phases are calculated, their names and calculation methods may vary slightly.

Activities in PRs 

Analyzing the number of comments, the activity of reviewers, and the speed of implementing changes gives insights into team collaboration, code quality, and the efficiency of the review process. A reasonable number of comments and constructive discussions often leads to higher-quality code and encourages collaboration within the team.

These metrics help evaluate the code review process and team interaction from different perspectives. Choosing those most important to you and looking at them holistically will help to build a more effective management system. Since sole monitoring of any metric might not always reveal the actual quality of the review process.

How to Find PR Statistics in Bitbucket

One of the ways to track pull request metrics is by using a third-party tool like Awesome Graphs for Bitbucket, which provides a comprehensive overview of the software development process in graphs and reports. Using this on-prem app makes finding the statistics you need, like the number of pull requests or their cycle time, easier, saves time, and allows you to make decisions based on data.