Improve pull request flow
Get visibility into your team’s pull requests and the contributing factors behind cycle time: the number of pull requests in progress, batch size, and review time.
Last updated
Was this helpful?
Get visibility into your team’s pull requests and the contributing factors behind cycle time: the number of pull requests in progress, batch size, and review time.
Last updated
Was this helpful?
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 , 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.
Being able to improve cycle time only requires the basic Swarmia configuration:
GitHub connected
At least one team created
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.
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.
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.
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 notifications for getting timely notifications of what should be done
Slack digests for 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
To use the Slack notifications, you’ll also need to .
You can also check your for the amount of Keeping The Lights On (KTLO) work.
