LogoLogo
Book a demoLog in
  • Swarmia documentation
  • Getting started
    • Get started in 15 minutes
    • Integrations
      • GitHub
        • GitHub Enterprise Server
        • Multiple GitHub organizations
        • Forked repositories
        • Troubleshooting
          • Reinstalling the Swarmia GitHub app
          • Updating app permissions
          • Installing Swarmia outside of GitHub Marketplace
      • Jira
        • Jira Server and Jira Data Center
        • Multiple Jira organizations
      • Linear
        • Private Linear teams
        • Disconnect Linear
      • Slack
        • Private Slack channels
      • Authentication
        • Google Single Sign-On
          • Frequently asked questions
        • Okta Single Sign-On
      • HR systems
      • Data export
        • Data cloud
        • Export data as a CSV file
      • Other integrations
        • Other issue tracker integrations
        • Other source code hosting integrations
  • Configuration and data quality
    • Teams & members
      • Creating & managing teams
        • Teams API
      • Contributors
      • Roles and permissions
      • Inviting team members
    • Issue tracker configuration
      • Jira configuration
      • Jira best practices
      • Linear configuration
    • Pull request exclusions
    • Linking pull requests to issues
    • Investment categories
    • Deployments
      • Generate deployments from merged pull requests
      • Generate deployments from GitHub deployments
      • Generate deployments from GitHub checks
      • Generate deployments via the API
        • Generate deployments for monorepos via the API
    • Sprint configuration
  • Use cases
    • Improve pull request flow
      • Pull request insights
      • Reducing pull request cycle time
      • Review code faster
      • Managing pull requests in progress with the Pull Request view
      • Diagnosing low pull request throughput
      • Analyzing pull request batch size
  • Improve your team's focus
    • Optimizing issue cycle time
    • Analyzing activity patterns on Work Log
    • Grouping activity on the Work Log view
    • Focus summary
  • Balance engineering investments
    • Activity and effort-based models
    • Categorizing work
    • Common problems with balancing engineering investment
  • Deliver strategic initiatives
    • Forecasting initiatives
  • Capitalize software development costs
  • Run developer experience surveys
    • Creating a survey
    • Managing surveys
    • Viewing and sharing survey results
    • How we show your survey responses
    • Survey communication guide and templates
  • Track DORA metrics
    • Automatic change failure detection
    • How Swarmia links PRs to deployments
  • Coach software developers
  • Get visibility into your CI pipeline
  • Continuous improvement
    • Working agreements
  • Notifications
    • Team notifications
    • Personal notifications
  • Retrospectives with Swarmia
  • Metrics & definitions
    • Pull request cycle time
      • What's the difference between "Change lead time" and "Pull request cycle time" metrics in Swarmia?
    • Issue cycle time
      • Defining issue lifecycle and cycle time
    • Developer effort (FTEs)
  • DORA metrics
    • Change lead time
    • Deployment frequency
    • Mean time to recovery
    • Change failure rate
  • Throughput
  • Time to deploy
  • Batch size
  • Flow efficiency
  • Scope creep
  • Sprints
  • Frequently asked questions
    • How do you treat weekends in metrics?
    • Tracking squashed commits
    • How do merge queues affect my metrics?
    • Why is my commit not visible in Swarmia?
    • How do I account for people leaving my organization?
  • Resources
    • Security & data retention
      • Data security
      • Data access
      • Swarmia IP Addresses
      • Single Sign-On (SSO) / SAML
      • Can I get a copy of the SOC 2 Type II audit report?
      • Deleting your organization
  • Pricing & plans
    • Compare plans
    • Free plan
    • Do I need a credit card to start a free trial?
    • What are the differences between the individual modules and the standard plan?
    • How do you determine the number of developers for billing?
    • What happens to customers with the Lite plan after the December 2024 pricing and plan change?
  • Changelog
On this page
  • Definition
  • Example
  • Why it matters
  • What's a good cycle time?
  • What contributes to cycle time?
  • Lowering cycle time with Swarmia

Was this helpful?

  1. Metrics & definitions

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.

PreviousRetrospectives with SwarmiaNextWhat's the difference between "Change lead time" and "Pull request cycle time" metrics in Swarmia?

Last updated 1 month ago

Was this helpful?

Definition

In Swarmia, a pull requests 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, that equals 2 days 'in progress'.

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

And finally, another full day passes between the final approval and the pull request being merged. That’s 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.

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 Pull Request overview to identify old pull requests and decide what to do with them.

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).

Build a feedback loop

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

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

Adopt a and set it to what you just decided.

To address specific issues contributing to cycle time, consider adopting a , and an agreement measuring specifically

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

pull request insights
exclude
pull request max age working agreement
work in progress target
review time
Swarmia's daily digest
Pull Request overview