This is the second installment of our Cycle Time Breakdown series on the most effective tactics to speed up your development Cycle Time. The other posts are:
- Tactics For Reducing Coding Time
- Tactics For Reducing Pull Request Pickup Time ← You are here
- Tactics For Reducing PR Review Time
- Tactics For Reducing Deploy Time
The Issue
You’ve grinded away on a piece of code – working out complex logic trees, thinking through corner cases, making everything clean – and finally it’s done. You create a pull request and wait for the review.
Then you wait some more.
And some more.
No one has noticed your pull request! This is especially frustrating because you specifically assigned the Pull Request to a teammate. You have no choice but to take the time to ping them over email or Slack to remind them about the review. No one wants to be a bother, but the review needs to be done, right?
Long Pickup Time for a Pull Request is frustrating for individual developers and for team leads. Code with a long time delay between PR creation and review was just sitting there idly, when it could have been deployed to production and been adding value for customers.
Software engineering managers should pay close attention to Pull Request Pickup Time, the second segment of a project’s journey along the Cycle Time path. (Go here for our blog post about the first segment, Coding Time.)
In this post, we’ll look at how you can make sure that PRs are reviewed in a timely manner and reduce lead time and overall cycle time. (In the other posts in this series, we look at how to reduce Coding Time and Pull Request Review Time.)
Table of Contents
- What is Pull Request Pickup Time?
- Causes of Slow Pull Request Pickup Times
- Investigating High Pull Request Pickup Times
- Recap: 3 Tactics for Reducing High Pull Request Pickup Times
- Parting Words
What is Pull Request Pickup Time?
PR Pickup Time is defined as the time it takes from when a pull request is issued until a review has started.
The question you may be asking is: How long should PR Pickup Time be? LinearB analyzed data from almost 2,000 teams and over 847,000 branches to establish benchmarks for key engineering metrics, including Pickup Time.
In the row “Pickup Time,” you can see that elite teams average less than seven hours. In other words, a PR created in the morning is typically reviewed by the end of that same day. In contrast, teams that are in need of serious improvement take over 19 hours on average.
With LinearB, you can get pull request metrics and know the Pickup Time among your engineering teams, precisely and in real-time. In fact, you can know how long every part of your Cycle Time is taking.
This is the LinearB Cycle Time overview. Without me even explaining, you probably know what this is telling you: Pickup Time is in red because it’s slow. The other parts of Cycle Time are in green so they’re fine.
And just that like that, you can see bottlenecks in your development cycle!
Causes of Slow Pull Request Pickup Times
There are three reasons why your team will have lengthy PR Pickup Times:
- Your team doesn’t know that the PR exists.
- Your team is too busy.
- The Pull Request is too large.
Your team doesn’t know that the PR exists.
As we all know, PRs easily go unnoticed or forgotten about. Perhaps the developer failed to assign the Pull Request to anyone. Or the reviewer saw the request then had to do one of the other 100 things on their plate and forgot about it.
This is a big problem, but thankfully it is also easy to solve. LinearB’s WorkerB automation bot can automatically send out notifications when a PR has been assigned to you. And perhaps even more valuable, WorkerB will remind you when you may have forgotten about a PR. This will greatly reduce average Pickup Time, and your teams will no longer have to spend valuable time reminding one another to review PRs.
Your team is too busy.
Devs have enough work of their own that needs to get done. Where can they find the time to do reviews? Often, developers keep putting off reviews or they figure that someone else will come along and pick it up.
One of the challenges for a team lead is balancing workload across a team. You want to make sure that the work is split equitably and that no one is being overworked. This not only helps to ensure everyone has time to spend on reviews, but it also optimizes overall development velocity in the short and long terms.
With LinearB, it is easy to see how your team is spending their time. You can see things like how many branches each developer is working on to determine their total Work in Progress (WIP). We’ll even alert you if a developer has maybe taken on too much work and is at risk of burning out.
The Pull Request is too large.
Opening a pull request is easy. Reviewing it is the hard part. But you can create pull requests that are easier to review, which will sped up Pickup Time and Review Time.
A big PR suggests that there are lots of changes and a lot of complexity to parse, which reviewers know is going to take a lot of time. So they put it off until tomorrow, when they will have a block of interrupted time and more energy to work through it all.
But then there is no time tomorrow or the next day or the day after that. All of a sudden, a whole week has passed and still that big PR is waiting for review!
LinearB analyzed 733,000 pull requests and 3.9 million comments from 26,000 developers. We were shocked to see just how long PRs sat idle:
50% of pull requests were idle for 50.4% of their lifespan.
33% of pull requests were idle for 77.8% of their lifespan.
We spend so much time optimizing other parts of the development process, like build and deployment, but there’s a much easier may to sped up development velocity: Speed up PR reviews!
And there’s an easy way to speed up reviews: Reduce Pull Request size. Our research found an almost exponential relationship between estimated review time and the time a dev takes to review a PR. Small PRs can get picked up 20x faster. PRs that can be reviewed at a glance can have near-instantaneous pickup times while big PRs can take days to get picked up.
Listen to LinearB’s Co-Founder and CEO, Ori Keren, explain further the impact of pull request size on development velocity at the 2022 DEVOPS Conference:
Based on our research, a good rule of thumb is that a PR shouldn’t contain more than 150 lines of code that have been changed.
Investigating High Pull Request Pickup Times
LinearB makes it easy to track and improve your Pull Request Pickup Time.
You can easily see a list of Hanging Review Requests. You can even configure the threshold that will determine which Review Requests will be flagged as “hanging.”
You can also monitor PR Pickup Time trends as well as other metrics like PR size and the number of comments on reviews, which is an indicator of review quality. There are also metrics for the code base as a whole, like a breakdown of how much time is being spent on each issue, epic, and branch.
To help you drive improvement, LinearB also allows you to create goals and track your progress against those goals. This helps you refine your code review process and motivates your team to get better.
Recap: 3 Tactics for Reducing High Pull Request Pickup Times
We’ve covered a number of tactics in this piece. Let’s recap them here:
- Use automated notifications to inform the devs on your team about PRs that they need to review.
- Monitor the amount of Work in Progress (WIP) each team member has taken on to ensure that everyone has the bandwidth for reviews.
- Keep PRs small so that they will be reviewed quickly.
With LinearB, it’s easy to do all three and increase the frequency and number of pull requests merged into production. To see just how easy, get in touch to set up some time for a demo.
To learn about other ways to reduce your Cycle Time, be sure to check out our posts on reducing Time to Merge and Coding Time.
Parting Words
The proliferation of the continuous integration/continuous deployment (CI/CD) software development paradigm means that development velocity is more important than ever. As we’ve seen, Pull Request Pickup Time can seriously slow down your overall Cycle Time.
But with LinearB, you can get a handle on things. You can know your precise Cycle Time as well as how long each component is taking. You can identify bottlenecks, set team goals for improvement, then use the WorkerB automation bot to drive progress.
Start using metrics with LinearB and turbocharge your teams!
