Market Leader in Development Analytics (G2 Crowd’s Winter, Summer & Spring 2022)
Backed by Y Combinator experience featured in TechCrunch
New Case Study: Learn how WOM leverage Waydev
Remote work? Learn how to gain visibility into your engineering teams and accelerate your product velocity.
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.
Identify the bottlenecks in your PR cycles over the course of the sprint. The PR resolution is designed to help you find outliers. Visualize high-level team dynamics and the underlying activities that can contribute to those dynamics.
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. 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.
The team can look at outliers, that is, the PRs that took an unusually long time to be resolved and work backward from there to figure out why those PRs, in particular. We’ll often see common tendencies here: the PRs are large, maybe the PR was submitted late on a Friday. Ideally, you can bring the report into retrospectives with a few hypotheses to spark a discussion, but remember that this is a team’s discussion about what patterns or trends are seen and causing PRs to take longer to resolve.
The PR resolution report can help you see both the high-level team level dynamics and the underlying activities that can contribute to those dynamics. You’ll be able to 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 team’s work to get through the review process to production.
As with all metrics, your team surfaces in retrospectives, identifying the most relevant data points for your team’s workflows, then gain buy-in with the team on targets that signal healthy development. Facilitate conversations on the why between your teams target, and actual, then determine which actions, if any, to take. Start incorporating metrics from the PR resolution into your retrospectives, and coaching opportunities will be easier to identify. It’ll be more obvious when processes need to be adjusted, and as a team, you can work towards a more collaborative, productive, and engaging code review process.
Ready to improve your teams' performance?