Improve the Pull Request Process with LinearB

Half of pull requests (PRs) are idle for 50% of their lifespan–which leads to increased cognitive load, developer toil, frustration, and negatively impacts quality and efficiency.

How to streamline the PR process

Code quality, efficiency, and planning accuracy rise and fall with the pull request–a.k.a “merge requests” for the Gitlab inclined. As PRs sit idle–because of size or lack of context–there’s an increased chance that errors will be missed, delays will occur, sprint goals won’t be met, and promises won’t be kept.

A developer can write immaculate code for a feature but if the end result is a massive, complex PR, there’s a good chance it will be rejected. Or worse, sit idle–leading to domino effect where developers are blocked waiting for approvals.

 All of these outcomes negatively affect project cost and timelines.

Ensuring code gets adequate, quick reviews and gets merged/deployed fast depends on several factors, namely PR size, clarity, context, and operations.

When all of these areas are optimized, then end result is:

Take a look at how you can improve and streamline your PR process.

Benchmark and baseline
your team’s PRs

Pop Quiz:

  • What’s the average size of your team’s pull requests?
  • How long does it take for PRs to get reviewed?
  • Does every PR get reviewed?
  • Are your averages being driven by a few outliers?
  • What tool(s) in your stack has this information?


Last question: How easy was it to find the answers to these questions? Answering these questions will be invaluable in determining how streamlined your PR process is. Ultimately it’s the PR process that determines cycle time (and engineering efficiency) and the quality of your code.

The first step in improving your PR process is to look into your pull request metrics (including size, idle time, review depth, PRs merged w/out review). You then need to find out if these metrics are consistent or the result of outliers.

Last, but not least, you need to contextualize these metrics with engineering benchmarks.

Showcase insights and best practices

If you explored our engineering benchmarks, you’ll know that a crucial leading indicator of an elite PR process is keeping PRs under 200 lines of code (LOC) or diffs. But improving the PR process isn’t just about the size of pull requests, it’s also about:

Teams can use LinearB to analyze leading indicators (PR size, pickup time, review time) and lagging indicators (CFR, MTTR) of a strong PR process and align the team to what works for PRs.

As an example, if CFR is high, PR sizes are 500 LOC, and pickup/review time are low–you’ll know that PRs aren’t getting adequate reviews and this needs to be a focal point of the team’s effort.



Use a portion of an upcoming retrospective or devote an ad-hoc session to sharing dashboards and metrics and ensuring that the whole team is on the same page concerning those metrics, best practices, and improvement goals.



Successfully completing this step relies on data–make sure you bring it.

Create team working agreements

Once your team is on the same page with best practices and overall goals, it’s time to action them by creating, documenting, and implementing team improvement goals.

These goals will vary by team and org but the overall process will be similar for most dev teams. Team goals should include both metrics contained in LinearB’s Team Goals and WorkerB as well as those that won’t be reflected in the tool.

To do this, you’ll need to:

  1. Figure out which aspects of the PR process your team needs to address (like PR size)
  2. Decide on how much you want to try to improve (we recommend one “tier” per quarter)
  3. Get buy in from the team around goals (both in LinearB and outside)
  4. Set your thresholds for Team Goals and put other working agreements in place. These should all reflect your team. Examples include: