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
  • Going faster helps the team
  • Check the current situation
  • Investigate throughput and trends
  • Zero in on code review
  • Increase visibility
  • Next steps

Was this helpful?

  1. Use cases
  2. Improve pull request flow

Review code faster

Code rarely ages well, and merging doesn’t get any easier over time. Here's how Swarmia helps your team get pull requests through faster.

PreviousReducing pull request cycle timeNextManaging pull requests in progress with the Pull Request view

Last updated 1 month ago

Was this helpful?

Going faster helps the team

Pull requests stick around for many reasons. Some are just too big, or the reviewer isn’t familiar with the context or the codebase. Sometimes reviewing and merging is thwarted by poor planning or lack of infrastructure, and often it’s just a case of poor visibility into review requests. Bottlenecks abound for pull requests, one of the most common being the code review.

Reviewing code quickly as a team comes with multiple benefits. Developers expand their comfort zone, the codebase becomes more robust, there’s a more frequent sense of accomplishment, and new features can be shipped faster. No matter the reasons for stuck pull requests, reviewing code without delay is always a good idea, and it’s always a challenge you must address as a team.

By managing the amount of work in progress and code review time, teams can significantly accelerate their pull request cycle times. After getting into the habit of quick code reviews, teams can expect to close 80% of pull requests within 48 hours, and rarely have to deal with pull requests older than 14 days.

Check the current situation

Lack of visibility is a common cause for stuck pull requests. Swarmia's gives a quick overview of what’s going on, and the charts give an idea of team throughput and bottlenecks. Getting in the habit of checking the from time to time goes a long way to ensuring that pull requests are moving.

The above Pull Request view tells you a lot about your situation. A large number of pull requests in progress is often a sign of a problem, and being able to see pull request ages helps you to understand its magnitude. The graphs above your pull request inbox give insights about cycle time and pull request throughput trends over time.

It’s normal that pull requests sometimes sit for a day or two before merging, but if many of your pull requests are weeks old, it’s time to dive deeper.

Investigate throughput and trends

In the above example, it looks like median review and cycle time are quite healthy, but there are plenty of outliers with high review times and cycle times. According to the Review Times scatter plot, a handful of pull requests have been waiting for review for quite some time, and while there are lots of pull requests assigned to other teams for review, they seem to be done quickly and are not the bottleneck. So, it looks like there are issues with code review that are worth addressing as a team!

Based on your team’s throughput over time, come up with an ambitious but realistic goal for pull request review time. Can you think of any reason why code reviews should take longer than three working days to complete? Talk it over with the team and stakeholders, and make sure to explain that reviewing code faster is a big step towards delivering features faster.

Zero in on code review

For most teams we see, code review is the bottleneck where progress stalls and throughput falters, making pull request review time a reliable leading indicator of total cycle time. Improving your team’s code review practices will go a long way towards speeding up pull request cycle times and improving team dynamics as a whole.

After configuring and adopting the new working agreement, outliers become clearly visible in context, exceptions from the past two weeks are spelled out, and the scatter plot highlights delays caused by cross-team collaboration.

In your next retrospective, review the list of exceptions together as a team. What made these pull requests so special? Getting in the habit of analyzing exceptions in retrospectives is all but guaranteed to regularly surface actionable insights about your process and lead to real improvements.

💁‍♀️ Review exceptions in retrospectives. Regularly going through recent exceptions to working agreements with your team is a great way to uncover insights about what’s holding you back and to systematically improve your review habits.

Increase visibility

While it’s important to analyze the reasons behind stuck pull requests in retrospect for systemic improvement, identifying and addressing problems right away can have an immediate impact on cycle times. Swarmia’s Slack notifications help your team preempt delays by increasing the team’s visibility into review requests, and detect problems as soon as they occur.

Encouraging team members to connect their personal Slack accounts, as well as connecting your team’s Slack channel in Swarmia, are great ways to increase visibility into review requests. When a review is requested from the team or an individual, Swarmia sends a notification either to the team’s channel or as a direct message.

To avoid redundant notifications, the original message is simply struck through after the review is completed and the pull request is merged.

Despite increased visibility, delays in reviews are bound to happen. To catch problems as they occur, set up the daily Slack digest for your team to understand what’s in progress and which pull requests need attention, and get timely feedback about working agreements that are slipping.

Exceptions in the Slack digest are your cue to revisit the Pull Request view, check which pull requests are problematic and have a short conversation as a team about what’s actually going on. Often getting unstuck is as simple as properly assigning the task or asking a quick question!

Next steps

When it looks like you’re consistently hitting your code review targets, it’s a good idea to dive deeper into the pull request cycle time, and explore issues of focus and work in progress. We recommend arranging a team discussion about limiting the amount of pull requests in progress at a given time, for which there is its own Working Agreement, as well as setting targets for pull request cycle time as a whole.

As you go on, the conversations you will have with your team about exceptions will help you surface all manner of improvements and spur you along on the path of continuous improvement. Good luck!

Before jumping into Swarmia’s to set throughput targets for your team, it’s worth the time to investigate past performance and estimate sustainable levels of throughput going forward.

is a good way to take a look at the pull request conundrum over a longer period. By reviewing past work in progress and cycle times, you can spot trends and begin to estimate realistic targets for future throughput. Importantly, pull request review time is often a reliable leading indicator of total cycle time.

To get started with improving your code review time, head over to and adopt a new agreement to review pull requests within a few working days, according to the analysis you’ve just made.

Working Agreements
Flow Insights
Working Agreements
Pull Request view
Pull Request view