Pull Request Cycle Time

Owned by Shir Koretski
Dec 20, 2024
5 min read

Evaluating Engineering Team Productivity

Overview

Pull Request (PR) Cycle Time measures the duration it takes for a PR to progress from creation to final merging into the codebase. This metric provides valuable insight into how efficiently code is being reviewed, approved, and deployed, helping to identify areas for improvement in the development workflow.

What Does This Metric Measure?

PR Cycle Time tracks the total time elapsed between the creation of a PR and its successful merge into the main codebase. This metric highlights the efficiency of the code review process and can identify delays or bottlenecks in the workflow.

How Is This Metric Calculated?

For each pull request, we measure the time from creation to first comment, first approval, last approval, and merge. The chart defaults to median but we recommend aggregating the data by average.

We recommend average over median because a vast majority of PRs for most teams are small, requiring minimal review time. This skews medians in an unhelpful and over-optimistic way.

General Filters

Use these filters to narrow down the information you want to see. After making any updates, make sure you click ‘update’ to have the changes reflect on the chart below.

 

  • Date Filter: For Pull Request Response Time, we recommend viewing the last three months or longer to find trends and directionality.

 

  • Descendants of: Limit the data by JIRA or ADO projects. You can also filter by projects or repo.

 

  • Pull Requests Created By: You can narrow down your search by tag labels as well as specific individuals.

 

  • Advanced Filters: Filter your data using properties located in your Git tools.

 

TIP: Make sure to apply the changes you made to General Filters by clicking ‘Update’.

Chart Settings

You can use chart settings to format how the chart displays your data.  This is powerful when it comes to creating data visualizations to support the story you’re trying to tell.

 

Commonly Asked Questions regarding PR cycle time:

 

Q: Is my individual team’s pull request review process timely? 

  • All teams vary, but a healthy PR creation to merge time is generally between one and three days. Less than one day, you might be letting PR reviews interrupt heads-down, focus work.

Any longer and the team needs to work on setting standards and a plan for reviewing PRs in a timely fashion.

 

Q: What is our PR cycle time on a month-by-month basis? Quarter over quarter?

PR cycle time grouped by month:

 

PR cycle time grouped by quarter:

 

Q: How do we compare PR cycle time across Tag-based data?

 

Q: What else can we use to make process improvements with this data?

  • Since this metric reports on long periods of time and groups by monthly or greater, you’ll want to pair this with Risks to keep a pulse on your progress.

For example, if you’re aiming for a PR creation to merge time of 3 days, you can set a risk that will remind you when a PR has been open for more than 2 days:

 

What Questions Can I Answer from This Data?

  1. How long does it take for pull requests to be reviewed and approved?
    This metric reveals the average duration it takes for pull requests to move from creation to merge, giving insight into team responsiveness and efficiency.

  2. Are there any bottlenecks or delays in the pull request process?
    Monitoring cycle time helps identify stages of the PR process where delays occur, such as lengthy reviews or excessive rounds of feedback, which may require process adjustments.

  3. Is the pull request cycle time consistent across different team members or reviewers?
    By comparing cycle times across team members, you can identify any disparities in review time or workload distribution, which may point to resource imbalances or inefficiencies.

  4. Are there any trends or patterns in the pull request cycle time that can help identify areas for improvement?
    Analyzing trends in PR cycle times over time allows you to spot patterns, such as slower times during certain phases or with specific reviewers, which can guide process optimization efforts.

What Should I Take Away from This Data?

  1. Measure Team Productivity
    PR cycle time serves as a key productivity indicator, reflecting the team's ability to review, approve, and merge code efficiently. Shorter cycle times often indicate a high-performing team, while longer cycle times can highlight areas needing improvement.

  2. Optimize Development Workflow
    By tracking cycle time, teams can identify delays and inefficiencies in their workflow, such as slow reviews or approval bottlenecks. This data can inform decisions about process improvements, the introduction of automation, or adjustments in resource allocation.

  3. Assess Collaboration and Responsiveness
    Faster PR cycle times often indicate a more responsive and collaborative team, while longer cycle times may point to communication breakdowns or overloaded team members. This can inform decisions about workload balancing and reviewer availability.

Conclusion

PR Cycle Time is a critical metric for evaluating the efficiency of your development team's workflow. By monitoring this metric, teams can identify delays, optimize their processes, and enhance productivity. Understanding and reducing PR cycle time helps ensure that code is reviewed, approved, and deployed efficiently, ultimately improving overall team performance and the speed of delivery.