# Improve pull request flow {% embed url="" %} Your ability to get code quickly to production translates to faster feedback loops, which in turn helps you build the right things faster. “Lead time for change” is one of the [DORA metrics](https://help.swarmia.com/metrics-and-definitions/dora-metrics), and it’s shown to correlate with better business performance. “Pull request cycle time” is one part of the “Lead time for change” metric, making it easier to improve and less susceptible to variations in deployment infrastructure. The cycle time is a systemic measure that’s affected by things like: * Code review process * Manual testing process * Amount of multitasking * Dependencies * Domain knowledge It is not an individual productivity metric. Cycle time for your most senior developers might be higher than for your junior developers, if one is working on your most challenging migration projects and the other is making copy changes to the website.

## Prerequisites & Setup Being able to improve cycle time only requires the basic Swarmia configuration: * GitHub connected * At least one team created To use the Slack or Microsoft Teams notifications, you’ll also need to [connect your Slack workspace](https://help.swarmia.com/getting-started/integrations/messaging-apps/slack) or [Microsoft Teams organization](https://help.swarmia.com/getting-started/integrations/messaging-apps/microsoft-teams). ## Using Swarmia To get a high-level overview of which teams might have a cycle time problem, start by looking at the organizational metrics.

To truly diagnose issues, you’ll need knowledge about the work itself. The team is best equipped to analyze its own work using one of the drill-down views.

Look at the pull requests that are taking the longest to merge, and see if you can spot a pattern. Click the pull request open to get more details, and see how much time it spent in different process stages. When you discover an outlier, add a note on it using [notes](https://help.swarmia.com/continuous-improvement/notes "mention").

To diagnose WIP (work in progress) or cross-team dependency issues, go to the pull requests page to see the work that’s currently in progress. Look at the code review statistics, and see if pull requests between teams are treated differently. Use the pull requests page to see incoming review requests in a clean inbox-like view. Try to close or merge any old stale PRs. If there are too many of them, exclude them from metrics to start from a clean slate, and try to keep it that way.

Sometimes high cycle time may indicate a team collaboration issue, such as siloing. In Work Log, you can see all coding contributions (including pull requests, reviews, commits, and comments) grouped by project or by contributor.

See Work Log’s bottom lanes for *bugs* and *other work*. Sometimes just keeping the lights on will keep your team busy.

You can also check your [investment balance](https://help.swarmia.com/use-cases/balance-engineering-investments) for the amount of Keeping The Lights On (KTLO) work. Smaller changes are easier to review and less risky. To make small changes, you might need to consider your Git branching strategy (optimally trunk-based) and enable infrastructure such as feature flags. In Swarmia, you’ll find a page dedicated to analyzing pull request batch size.

## Taking action One of the best ways to accelerate code to production is to create awareness of the current status of pull requests. You can do this by getting the team to adopt: * Pull request view to see the current “inbox” of your team * Slack or Microsoft Teams notifications for getting timely notifications of what should be done * Digests for Slack and Microsoft Teams reminding the team about the work on a weekly or daily basis * Working agreements for defining how you’d like to split work into small increments * Merge pull requests in X days * Review pull requests in X days * Limit the number of pull requests in progress to X days