Pull Request Cycle Time measures the time from creation to merge. It is based on the creator or author of the PR enabled on the team level settings.

Why should I measure Pull Request Cycle Time?

The faster a team moves to review and merge pull requests, the faster problems can be caught and dealt with, and ultimately the faster value gets into the hands of users. By reviewing PR response times, you can see where the bottlenecks are occurring in your team’s PR process.

Think of PR cycle time as a component of a sprint. If your average PR cycle time is four days, that’s almost half a typical sprint. That means code isn’t being submitted in the first half of the sprint, and may have trouble getting reviewed by the end of the sprint.

What metric should I use in Allstacks?

We recommend starting with the ‘Pull Request Response Time’ metric as it contains PR cycle time as well as additional details.

Under: Metrics > Code Review > Pull Request Response Time

How It's Generated

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: