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:
Higher quality code
Increased efficiency
Less developer toil due to pull request ping pong
More features shipped on time, promises kept, and value delivered
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.

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:

Breaking work down into smaller pieces
Providing appropriate context for reviewers
An issue and/or PR should do one thing (a.k.a single responsibility principle)
Accurately evaluating level of effort for PRs (i.e. ship, show, ask)

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:

Keeping PRs to <250 LOC**
Reviewing PRs in <12 hours**
Reviewing PRs at a consistent time--like early in the workday
Giving PRs appropriate levels of review (i.e. a PR with 2 LOC changes
probably doesn’t need 2 full reviews)
Agreeing that PRs get two reviews
We’ve been using hunches and limited data from our issue tracker in our sprint planning meetings.

Project Delivery Tracker helped increase our planning accuracy and made our meetings more productive.

Boaz Ben-Chaim

Dev Team Lead at Rapid7

Curious about the relationship
between idle time and PRs?

the pr paradox
inline approval slack product image

Automate good habits

Now that team improvement goals are in place, it’s time to give developers the tools they need to succeed--because none of this actually matters without a way to actually improve. Enter workflow optimization with WorkerB.

This automated bot, purpose built to streamline PR workflows for developers automates every aspect and makes their lives easier. It integrates with the tools your devs use most and sends real-time alerts on in-flight PRs.

First, set your thresholds (with your team). LinearB will estimate how many alerts will be generated so you can do what makes sense and is realistic. Developers use WorkerB to optimize and streamline their non-coding time and stay on track regarding their team working agreements.

And don’t worry, devs can snooze alerts when it’s time for deep focus work.

Devs can use WorkerB (personal and Team Goals) to:

Automate many annoying non-coding tasks and focus on problem solving
Create tickets, alter PR size, pickup PRs and take action quickly
Request reviews and add context to PRs
Get PR status, team goals, hanging reviews, CI job failures
Review and approve PRs (actual code snippets) from Slack
Get heads up alerts if PRs aren’t aligned to goals

Measure the impact

Now that your team is hitting goals for PRs, it’s time to check progress, celebrate wins, and recalibrate with the team as needed. We recommend doing this every third iteration.

Start by looking at the Team Goals dashboard to see how the team is doing with the working agreements they set (don’t hesitate to share this info with the team). See what impact this has on other metrics like Planning Accuracy or Throughput (for Kanban teams). You can also look to see how PR process improvement affects your delivery, quality, and DORA metrics.

If everything is working and you’ve reached your improvement goals of one tier up, see if you can take it a step further. If something isn’t working (like a “two reviews per PR” policy or <300 LOC threshold is sending too many alerts), you can address it with the team and adjust goals as necessary.

Regularly checking in with the team on goals, working agreements, and metrics will help them improve and deliver more value.

The benefits of improving
the PR process with LinearB

For developers
Self-advocacy with more visibility into all work during a sprint
Better alignment to the priorities of the team and the organization
Fewer fire drills & tasks that are tedious or just no fun
For managers
Decrease cycle time, ship more features, and deliver more value
Remove common blockers and developer toil
Plan sprints more accurately with reduced carryover due to long reviews
For leaders
Push code through development cycle faster for more feature delivery
Deliver on promises to the business
Empower developers to become elite and deliver more business value

Want to build the
perfect pull request?

study for

Improve Planning Accuracy

Check out how to use LinearB to plan iterations more accurately
Explore Next

Improve Engineering Efficiency

Learn more about Cycle Time and how to reduce yours with LinearB
Explore Next