Improve
Pull Request Process with LinearBcognitive load, developer toil, frustration, and negatively impacts quality and efficiency.
How to streamline the PR process
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:
Benchmark and baseline
your team’s PRs
- 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?
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:
probably doesn’t need 2 full 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.
Curious about the relationship
between idle time and PRs?
investigatethe pr paradox
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:
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
Want to build the
perfect pull request?
study foranatomy