The Issue

There’s nothing worse than working hard for a day or two on a difficult piece of code, creating a pull request for it, and having no one pay attention or even notice. It’s especially frustrating if you specifically assign the Pull Request to a teammate. It’s a bother to have to remember to send emails or slack messages to fellow team members to get them to do a review. No one wants to be a distraction, but the work has to be done, right?

So naturally, the conscientious Dev Manager will want to pay close attention to Pull Request Pickup Time (PR Pickup Time), the second segment of a project’s journey along the Cycle Time path. (Go here for the blog post about the first segment, Coding Time) She’ll want to make sure those frustrations described above don’t occur. Keeping Cycle Time “all green” is the goal, but this is often difficult because there are a lot of moving parts that go into managing Cycle Time, including PR Pickup Time.

PR Pickup Time is defined as the time it takes from when a pull request is issued until a review has started. Ideally, PR Pickup Time would be measured in minutes. Anything over a day should be considered worrisome.

However, these days, managers are demanding more — they want hard data. LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of the status of your PR Pickup Time. This dashboard is data-driven, based on the work committed to your code repository.

In this graphic, you can see that pickup time is red. That is, you can quickly and easily visually identify workflow bottlenecks using LinearB’s Cycle Time breakdown.

So how does this happen and what can you do about it?

What's the cause of slow PR Pickup Times?

There are three reasons why your repository will have a high PR Pickup Time:

1. The team doesn’t know the PR exists

2. The team is too busy

3. The Pull Request is too large

The team doesn’t know the PR exists

It may be as simple as the team doesn’t know that a Pull Request is waiting to be picked up. Perhaps the developer failed to assign the Pull Request to anyone. If the process is for the requesting developer to send out an email to the team announcing the Pull Request, and he forgets, then it is much less likely that anyone will know the Pull Request exists.

The team is too busy

Teams and developers that have high Work in Progress (WIP) are less likely to quickly pick up a Pull Request. They may feel pressure to get their current task completed, and don’t feel free to stop work and perform a code review. They may figure that someone else will come along and pick it up.

The Pull Request is too large

A large pull request can be daunting, and many developers may hesitate to take on a large code review, perhaps hoping another developer will jump in and take on the task. Our experience with customers at LinearB is that any Pull Request with over 200 changes will result in hesitancy by developers to do the code review.

Investigating High PR Pickup Time

Tracking PR Pickup Time is very straightforward in LinearB.

First, you can easily see a list of Review Requests Hanging on your LinearB Dashboard.

Simply click on the drill-down arrow in the upper right corner of the Dashboard, select the Pull Request tab, and click on “Review Request Hanging” and set your search criteria as desired.

This listing will include all Pull Requests that haven’t been picked up after a configurable amount of time.

Second, you can monitor PR Pickup Time trends in a metric in a Custom Dashboard.

This metric can tell you how your team is performing over time with regard to pickup time. Obviously, you want this metric to be as low as possible. Here you can see that PR Pickup Time was good until the “Suns” iteration when the pickup time jumped to a sub-optimal level.

5 Tactics for Reducing High PR Pickup Time

Naturally, once you realize that your PR Pickup Time is climbing, you’ll want to do something about it. LinearB gives you a number of ways to track things and take action with your team.

Ensure Work In Progress (WIP) isn’t too high

As mentioned above, busy teams often tend to avoid picking up Pull Requests, wanting instead to finish their work — work that is too much to allow for code reviews.

You can monitor the level of WIP that developers have via the Pulse View. The Pulse View is available in the menu on the upper right of LinearB’s header.

Here you can see that the selected developer Ashley is currently working on four separate projects, indicated by the four rows in the view. This number of projects is often too many. He will be less likely to want to pick up a Pull Request as a result.

It’s best to keep WIP at a level that allows developers time to do code reviews.

Keep PR Size as small as possible

Keeping the size of your Pull Requests as small as possible has many benefits, including making it more likely that a developer will take on the task of reviewing the code in the pull request.

In working with our customers, we’ve found that the very best teams keep their Pull Request Size below 150 changes. Low Pull Request Size results in lower Coding Time, better Review Time, and yes, better PR Pickup Time.

Use Real-Time Automation to keep Pull Request moving

WorkerB is designed to give notifications when events happen (or sometimes don’t happen) in your code repository.

For example, WorkerB will notify a developer when she has been assigned a Pull Request. This makes it much more likely that she will actually pick it up.

WorkerB will also notify the development team when a Pull Request has not been picked up for a configurable period of time.

LinearB customers see a drastic reduction in Cycle Time when using WorkerB, averaging a 50% decrease.

You can learn more about connecting up WorkerB in our documentation.

If you are not already using LinearB and want to do things like track Cycle Time and Pull Request Size, sign up for a free demo of the product today!

Configure a Custom Dashboard to start tracking Pickup Time

LinearB provides many different metrics that you can use to monitor what is happening inside your development environment. You can even create custom dashboards that enable you to see specific insights. For example, you could set up a custom dashboard to monitor the status of your pull requests, ensuring that they are processed in a timely manner.

The Pull Request process is the heart of your software development life cycle. By optimizing it, you can see drastic reductions in Cycle Time, which means more value being delivered to your customers faster. Pull Requests should be picked up quickly, reviewed in a complete and timely manner, and then merged promptly.

Above is a dashboard that tracks Pickup Time as well as Review Time, Review Depth, and Pull Requests merged without a review. In one glance, you can get a notion about the health of your whole Pull Request process.

The End Result

Keeping PR Pickup Time, and thus Cycle Time, under control is a critical means to continuously improving your software development process. By monitoring Pull Request size, engaging WorkerB, and monitoring Work in Progress, you can see your Cycle Time drop like a rock.

Imagine a world where you simply monitor the progress of your Pull Requests and in less than one quarter, you see your PR Pickup Time and other Pull Request metrics drastically improve merely by doing that monitoring. Say you are able to decrease your PR Pickup Time from three days to four hours. That alone is a 68-hour — almost the whole three days! — reduction in overall Cycle Time. Your boss will be impressed.

LinearB can make such a world happen, and happen fast. Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like drastically reduct your Cycle Time and Pull Request Size, sign up for a free demo of the product today!

Originally published at https://linearb.io on July 23, 2021.