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.

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:

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:

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.