These days, data and analytics have facilitated quantifying almost everything. This is no less true for software development teams whose productivity is measured by a wide variety of systems and software dev metrics. Using metrics from Pull requests (PR) are one of them.
Simply put, pull requests allow software dev teams to work with a single master source code at the same time without affecting the master code. This has many benefits, including enabling each team member to create their own iterations without risking the integrity of the source code.
In this article, we take a closer look at what pull requests are, what makes a good pull request, how they can be used as dev team metrics, and specific pull request metrics you can use.
Table of Contents
What Is a Pull Request?
A pull request is a feature introduced by GitHub to streamline and mitigate risks in the software development life cycle. Since software development teams often work on the same master code, they have to be able to do so without compromising the source code.
The pull request happens when a developer has finished working on a section of the code and wants the new code to be integrated with the source code. Because of PR workflows, developers, engineers, and programmers can submit their contributions using distributed version control systems (DVCS) like Git without causing problems to the work that has already been done to the master code.
Each PR submitted is scrutinized and tested before being merged with the source code. Code review means evaluating the PR based on metrics such as code complexity, code reviews, code churn, velocity (or rate of progress), and utilization. The results of a PR request merge can then be compared to the target branch baseline (BL). If deemed incompatible, the software developer can keep working on the code without affecting the entire project.
Here’s a snapshot of the process:
PR created along with PR comments → Code is reviewed and tested → PR merged if code is approved or sent back for revisions
What Makes a Good Pull Request?
Good pull requests are easy to review and are quickly merged with the source code. In this section, we examine the characteristics of a good pull request:
Suggest Changes Before Doing the Work
Before developers start working on the branch, ask them to discuss their ideas and the changes they want to implement. This can save valuable hours and help avoid code churn.
Right PR Size
Lengthy code takes longer to review. If it doesn’t get approved, it also means a lot of wasted hours. Make your PR the right size. Changes should ideally be no more than 300 lines.
Provide Context
Ask developers to provide context for the code by adding comments that explain their approach and why certain lines were added.
The best practice is to add a summary of the pull request and relevant links.
Pull Requests as an Indication of Dev Team Performance
Reviewing pull request metrics can provide you with useful information. It can tell you how well your team is progressing while enabling you to better manage your project.
It lets you:
- Identify development process bottlenecks
- Review development workflows based on PR activity
- Review how well your team collaborates through comments, discussions, and review analytics
How can you effectively use pull request metrics? Check out our next section on specific metrics.
Some Pull Request Metrics You Can Use
These pull request metrics can help you measure your progress and can help you identify and address potential bottlenecks in the workflow. Remember, however, that these should not be used to categorically define an employee or team’s performance.
Let’s take a look.
Merge Time
This metric takes into account the time from PR creation to merge.
To gauge time before pull requests, take note of the difference between the first commit’s timestamp and the date and time when the merge took place.
This metric is useful because it can tell you if work is progressing too slowly or too quickly.
Cycle Time
How much time does it take from the developer’s first commit to be merged? While merge time considers the time between PR creation to merge, cycle time or lead time only measures time from the first commit to the merge.
Find the average lead time by calculating the difference between the date and time for the first commit as well as the date and time when each PR was merged.
When analyzing cycle time, you can evaluate by repository or take into account all the repositories in your company.
Measuring lead time is often useful for identifying potential delays early on and over time allows you to notice patterns.
PR Size
A short merge time doesn’t tell the entire story. A merge can take longer because the pull request is bigger. PR size takes this into account by allowing you to measure the size of a pull request.
This is derived by adding together how many lines of code were removed and added in. The higher it is, the bigger the PR size that your team is dealing with.
Ratio of Opened to Closed Pull Requests
Is your team opening more pull requests than it’s closing? This metric will allow you to track if you have a good pipeline of pull requests that are being opened and closed daily.
Measuring this is easy — just keep track of how many pull requests are opened and closed each day. The closer you are to a 1:1 ratio, the more on track you’ll be with your delivery.
If your team is doing poorly in this metric, it may be because they aren’t working on the most urgent deliverables or the team is unable to keep up with rapidly changing priorities (like product requirements that are always changing).
PR Throughput Per Contributor
This refers to how many pull requests on average an engineer merges over a specific period. You can measure this on a weekly, monthly, or quarterly basis to assess how much work is being done, allowing better decision-making and enabling managers to make more accurate forecasts and better hiring decisions.
PR Discussions
Pull request discussions, comments, and reactions are good for team collaboration but too much of them can be a waste of time. While some PRs understandably need more input and collaboration than others, lengthy discussions shouldn’t be the norm.
Conclusion
Measuring PR activity with these metrics can improve your dev cycle time. They allow you to keep an eye on important numbers so that you can spot trends and potential bottlenecks before it’s too late.
Hatica is a software engineering analytics platform that measures PR activity, cycle time, and 80+ engineering metrics to equip leaders with data and insights to lead great engineering teams. Learn more: https://www.hatica.io/
