Pull request cycle time

Pull request cycle time (or PR cycle time) is the total time a pull request spends in all stages of the development pipeline.

Definition

In Swarmia, pull request cycle time is the sum of these three components:

• Time in progress — from the first commit or from when the pull request is opened, whichever happens first, to the first review request.

• Time in review — from the first review request (or from when the pull request was opened, if none) to the final approval.

• Time to merge — from the final approval to once the pull request is merged.

Example

A pull request is opened on a Monday, and then the first review is requested on Wednesday, which equals 2 days in progress.

Then that pull request takes another day for review approval, which equals 1 day in review.

And finally, another full day passes between the final approval and the pull request being merged. That’s a 1-day time to merge.

Together, this equals a pull request cycle time of 4 days.

The average PR cycle time for a given time period would be the cycle time of all pull requests in that time period, averaged.

Why it matters

Lower cycle time means:

• Shipping in small batches without interruptions

• Getting feedback from end users faster

• Reducing risk and overhead

• Reviewing and merging new code quickly

What's a good cycle time?

According to the authors of Accelerate, “elite” teams reach a cycle time of less than a day, while high-performing teams deliver code in under 7 days on average.

Use pull request insights to look into cycle time and other pull request metrics in Swarmia.

What contributes to cycle time?

Let's consider the key factors contributing to cycle time and how you can impact them. Among others, we suggest focusing on the following:

• Work in progress queue: Working on too many pull requests at once often correlates with longer delivery times. Use Swarmia's WIP working agreement to agree on a target with the team (e.g., up to 10 pull requests open at once) and keep track of it over time.

• Time in progress: Shorter in-progress time means focusing on splitting work into smaller batches that are easy to plan, review, and deploy.

• Time in review: Creating smaller pull requests that are easy to review, using code owners in GitHub to assign reviewers automatically once a pull request is open, are some ways to lower review time.

• Pull request size: Smaller pull requests are easier to plan, review, and deploy.

• Time to merge: Making approved pull requests a priority, agreeing on merge rituals with the team (Who has the responsibility to drive the pull request forward? Who can merge code?), and investing in production infrastructure helps to reduce waiting time between approval and merge.

Lowering cycle time with Swarmia

Start with a clean-up

If measuring cycle time wasn't ever a priority, there are likely some very old pull requests waiting to be closed. Use the Pull Request overview to identify old pull requests and decide what to do with them.

To get a more relevant view of your data, exclude outlier pull requests from all metrics. This lets you focus on lowering cycle time for newly opened pull requests.

You can bulk exclude all pull requests that have been open for a month or longer, or archive individual ones. We recommend starting with the bulk exclusion, as you can include any excluded pull requests back into metrics later.

Adopt a working agreement

Once you've identified cycle time as an improvement area, look at the Pull Request insights together with the team:

• Decide what a realistic maximum target is (7 to 14 days is a good starting point).

• Adopt a pull request max age working agreement and set it to what you just decided.

• To address specific issues contributing to cycle time, consider adopting a work-in-progress target and an agreement measuring review time specifically

Build a feedback loop

Enable Swarmia's daily digest in Slack to get a daily reminder about pull requests not adhering to the agreement. Check the Pull Request overview regularly with the team to spot emerging coding patterns early and close pull requests before they get old and stale.

Frequently asked questions

How are draft PRs considered in cycle time?

We consider all PRs the same, regardless of the draft state. Since PR cycle time starts from the first commit (or PR open, whichever happens first), the total cycle time is the same, regardless of whether you open a PR as a draft early or ready to review later.

In other words, we consider the draft status by default to be part of the in-progress time. Our definition is based on the assumption that draft pull requests are used as an early indication of work in progress or to gather feedback before review. We try to catch as much of the in-progress time for pull requests as possible.

If you want to exclude draft PRs from Swarmia until they are ready to review, you can set a "Draft status is Draft" exclusion rule. This can be useful, for example, if you create proof-of-concept draft PRs with no intention to merge or close them. Another option would be to create a dedicated PR label for this and use it in the exclusion rule.