The importance of Changes & Reviews and Work in Progress metrics

To continuously improve and deliver better software development productivity, you must have the right data to make better decisions. Having the means to measure and evaluate the effectiveness of the software development strategy is a key factor in setting and achieving your goals.We previously discussed how the DORA metrics could give you valuable insights to optimize your software deliveries and help your team focus on continuously providing value. Today, we’ll discuss the Changes & Reviews and Work in Progress metrics.

These metrics, all available in Codacy Pulse, can help you understand how long Pull Requests take to be merged, how much code reviews contribute to delaying your workflow, what ongoing code reviews need your attention, and what impact a static code analysis tool like Codacy Quality can have on your team.

Changes & Reviews metrics

Changes & Reviews metrics provide an extra level of detail about the performance of your team workflows.

Changes metrics

Changes metrics directly influence Lead time for changes (how long a commit takes to reach production) and can help you track in more detail what you need to improve in your workflow. Metrics corresponding to the stages of their development pipeline, like Time to open and Time to merge, help identify bottlenecks in your team’s processes. 

• Time to open approximates how long a change or feature takes to develop. It provides insights into the development process’s efficiency, the code’s quality, and how team members communicate or collaborate. Pulse calculates the Time to open metric with the following formula:
  • pull request open timestamp - first commit in pull request branch timestamp

• Time to merge shows how long the code review process takes for a change or feature. It provides insights into the efficiency of the code review process. This metric can help teams identify bottlenecks that are delaying the merge of PRs, like code quality issues, dependencies on other changes, or inefficiencies in the approval process. Pulse calculates the Time to merge metric with the following formula:
  • pull request merge timestamp - pull request open timestamp

Both Time to open and Time to merge can impact the overall efficiency of your team. If changes take a long time to be opened or merged, it can slow down the development process and potentially cause delays in the delivery of new features or bug fixes. Monitoring these metrics can help you make the corresponding changes to improve your team’s processes.

Reviews metrics

Reviews metrics measure the time it takes for a change to be reviewed and approved. They are critical for understanding your code review process’s level of engagement and efficiency. Reviews metrics are the following: Time to first review, Time to first approval, Time from first to last approval, and Time from last approval to merge.

• Time to first review shows how long it takes to have the first review on a Pull Request. It provides insights into reviewers’ availability, the priority of the change, or its complexity. Pulse calculates the Time to first review metric with the following formula:
  • first review timestamp - pull request open timestamp

• Time to first approval shows how long it takes to have the first approval on a Pull Request. It provides insights into reviewers’ workload and agreements or the complexity of the change. Pulse calculated the Time to first approval metric with the following formula:
  • first approval timestamp - pull request open timestamp
    
    
• Time from first to last approval shows how long it takes between the first and last approvals on a Pull Request. It provides insights into reviewers’ workload, the complexity of the changes, or the number of required approvals. Pulse calculates the Time from first to last approval metric with the following formula:
  • last approval timestamp - first approval timestamp
  
  
  
• Time from last approval to merge shows how long it takes to merge a Pull Request after the last approval. It provides insights into merge conflicts and the overall merge process. Pulse calculates the Time from last approval to merge metric with the following formula:
  • pull request merge timestamp - last approval timestamp

These four metrics can impact the speed and effectiveness of your code review process. Monitoring these metrics can help you identify bottlenecks and make changes to improve the code review process. These changes include providing more resources for reviewers, prioritizing changes, breaking down complex changes into smaller pieces, or streamlining the merge process.

Work in Progress metrics

The Work in Progress metric measures the number of Pull Requests your team still needs to merge into the codebase. By monitoring this metric, you can:

• Identify areas for improvement: If this metric consistently shows many open PRs, it may indicate a bottleneck in the code review process.
• Manage workload: Teams can manage and prioritize PRs to review, ensuring the most critical changes are integrated into the codebase as quickly as possible.
• Ensure efficiency: Teams can ensure their review process is efficient and that they are integrating changes into the codebase on time.

To provide you with a high-level view of the current work in progress of your teams, Codacy Pulse groups Pull Requests that are currently open by the following phases:

• Open: The Pull Request is open, but the team needs to review it.
• Reviewed: The Pull Request received at least one review but has yet to be approved. These reviews include change requests and inline PR comments but don’t include conversation comments.
• Approved: The Pull Request received at least one approval.

The following metrics for each open PR allow you to understand which work items are about to become or have become blockers and may need action to move forward:

• Time in progress: Time since that PR is in progress.
• Phase: The current phase of the PR. As we saw before, it can be one of Open, Reviewed, or Approved.
• Reviews: The number of reviews of the PR. Reviews include approvals, change requests, and inline PR comments but don’t include conversation comments.
• Comments: The number of comments on the PR. Comments include inline pull request comments and conversation comments.
• Time stale: The number of days since the PR’s last interaction.
• Changes: The number of lines of code changed by the PR.

Conclusion

Changes & Reviews and Work in Progress metrics can provide extra information to your team and help you make informed decisions to improve your development processes and increase efficiency.

By monitoring these metrics, your team can identify any bottlenecks in the code review process and make changes to improve it. Changes include providing more training and resources for reviewers, enhancing communication and collaboration between developers and reviewers, streamlining the code review process, or improving the quality of changes.

Empower your team with the DORA, Changes & Reviews, and Work in Progress metrics. Connect Pulse with GitHub or Bitbucket today to find out which capabilities impact your organization the most and start improving your Engineering health.