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.
Last updated
Was this helpful?
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.
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.
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.
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.
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!
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.
