Waydev's PR Workflow analytics bundles up all the features you need to identify bottlenecks, long-running or unreviewed pull-requests, so you have a better understanding of PRs and improve your engineers’ performance.
Enable a culture of productive code reviews, positive practices, and better team dynamics. Using the PR workflow analytics tool, you can boost code review productivity and reinforce positive patterns across your team. Waydev analyzes PRs with the help of 4 different PR workflow features that ultimately help you understand and determine if your team’s review workflow objectives are on track.
PR Resolution – Identify the bottlenecks in your PR cycles
Review Workflow – View a map of pull request activity
Review Collaboration – Check a unified view of submitter and reviewer metrics of the PR process
Fundamentals – Determine if your code review workflow objectives are on track
Identify the bottlenecks in your PR cycles over the course of the sprint. Find outliers, visualize high-level team dynamics and the underlying activities that can contribute to those dynamics.
The PR resolution report is designed to help you see how metrics like Time to First Comment, Number of Reviewers, and Number of Follow-on Commits are leading indicators of Time to Resolve, or how long it takes for your teams’ work to get through the review process to production.
The PR Resolution feature can help you identify the bottlenecks in your PR cycles over the course of the sprint.
This report focuses on six core PR cycle metrics:
Time to Resolve (a PR in hours)
Time to First Comment (in hours)
Number of Follow-on Commits
Number of reviewers on a PR
Number of reviewer comments on a PR
And the Average number of comments per reviewer.
Here is how you can use the PR Resolution feature:
While these metrics can be a high-level benchmarking, the PR resolution is designed to help you find outliers.
The primary thing to pay attention to is when something jumps out as noticeably out of the ordinary. This really helps to see the ground truth of your code review and can be a great visualization to incorporate into team retrospectives.
One of the biggest sources of pain and frustration in the delivery process is when an engineer opens a PR, and then they wait an enormous time before the reviewer picks it up. Time to resolve is the time that it takes for a pull request to be resolved, whether that means merging it, closing it, or withdrawing it. This metric looks at the broader picture of how work is being handled during the review process.
View a map of pull request activity in the selected time frame. Identify long-running pull requests, unreviewed pull requests that have been merged, and spot closed pull requests that have not been merged.
PRs opened before the selected period are included if they were open during the selected period. Use this report as your starting place for a birds-eye view of all Pull Request activity.
You can select which team’s review workflow to see, which repositories’ review workflow to see, what period should the review workflow span to, as well as what type of workflow reviews to see (open, merged, closed, or all).
One of the uses of the Review Workflow is to identify long-running pull requests, zoom into them and point out what is keeping that pull request from being merged. It can be a late review, unclear requirements, or multiple follow-on commits.
Another use of the Review Workflow is to identify the pull requests that have been merged without review. They are displayed in yellow. Such pull requests can raise critical issues if done by a less experienced engineer.
You can also spot closed pull requests that have not been merged. They are displayed in grey. Closed pull requests that have not been merged indicate unproductive work.
The bars represent the time it took for a pull request to close, while the numbers on the right side of the page are the pull request’s ID.
The bubbles indicate a follow-on commit, while the half bars indicate the comments. If you click on a bar, details about that particular pull request will pop up.
You can see the pull request ID, the engineer that created the pull request, when it was opened and when it was merged, how much time passed until the first comment, the work level, the number of commits, the number of comments, the number of reviews and its status.
You will also see a timeline of the follow-on commits and comments on the pull request. If you click on a commit title, the commit page from the Git provider will open in a new window.
Understand how your engineering teams work collaboratively. Effectively communicate the healthy tension between speed and thoroughness in code review.
Review Collaboration shows code collaboration stats between the submitters and the reviewers. Engineers can play the role of both submitters and reviewers.
You can select which team’s review collaboration stats to view, which repositories, and what time frame to analyze.
Responsiveness and Reaction Time help you understand how quickly the team members are communicating with each other in reviews. A healthy code review workflow should aim to improve the velocity of code review communication.
Involvement represents the percentage of PRs a reviewer participated in. It provides a measure of the engineering engagement in the code review process.
Comments addressed is the percentage of Reviewer comments that were responded to with a comment or a code revision.
Receptiveness is the ratio of follow-on commits to comments. This is an indicator of openness to constructive feedback, but you should never expect this metric to go up to 100%. This would mean that every comment leads to a change.
Influence is a ratio of follow-on commits made after the reviewer commented. When this metric is viewed across a longer period of time, it can provide some insight into the likelihood that reviewers’ comments will lead to a follow on commit, thus their influence.
Unreviewed PRs help you measure the thoroughness of the feedback. It shows you the number of pull requests that are open and merged without ever getting a comment.
The Review Coverage indicates the number of pull requests that have been merged after review, and engineering leaders should try to bring this metric as close as possible to 100%. It helps get an understanding of the thoroughness of a review between the submitter metrics and the reviewer metrics.
The Sharing Index report displays the evolution of knowledge sharing throughout the organization. It is the ratio of active reviewers to submitters. Active reviewers is the count of active users who actually reviewed a PR in the selected time period. Submitters represent the total number of users who submitted a PR in the selected time period.
The Review Collaboration feature also includes a map of code collaboration. If you hover over an engineer’s name in the right column, you will see whose pull requests they reviewed. This is useful to gain insights about whether your senior engineers are active in the code review process.
The Submitter Fundamentals and Reviewer Fundamentals provide a view of how the metrics from the Review Collaboration evolved over time. These features should be used as a gauge to determine if your objectives regarding the code review workflow are on track.
You can select which team’s performance to view, which repositories’ contribution to analyze, and what period to inspect.
Each metric has its own average value which you can see in the tab view or on the left side of the chart. For example, if you see that over a quarter, the Unreviewed PRs percentage dropped from 40% to 20%, this translates into a lower risk of solutions delivered.
Reviewer Fundamentals offers an overview of the reviewers’ metrics.
You can select which team’s performance to view, which repositories’ contribution to analyze, and what period to inspect. Each metric has its own average value which you can see in the tab view or on the left side of the chart.
Unlock the value of your team’s Git workflow analytics
Waydev’s PR Workflow analytics bundles up all the features you need to identify bottlenecks, long-running or unreviewed pull-requests, so you have a better understanding of PRs and improve your engineers’ performance.