Pull Request Throughput is the simplest, most powerful engineering metric you are probably not tracking. Learn why it should be the foundation of every engineering leader's metric playbook and how it illuminates whether work is actually flowing through your team.
Tracking pull request throughput should be the bedrock of every engineering leader's metric playbook.
DORA, SPACE, DevEx, DX Core4, and all the popular ones assume you deploy to production constantly. Not everyone works in an industry or on a product where it is reasonable or safe to push to production multiple times a day. The vast majority of companies do not have pristine CI pipelines and flawless automation. But that shouldn't stop you from tracking meaningful metrics.
Whether you ship weekly, bi-weekly, quarterly, or when a steering committee nods solemnly, your engineering team merges code, and you can track that.
Before you can fix a system, you have to objectively see it. Most engineering leaders are operating without visibility into whether work is actually flowing through their teams. Pull Request Throughput can be that flashlight. And the good news is you already have everything you need to turn it on; the data is sitting in your version control system right now waiting for you.
At its simplest:
Pull Request Throughput = Number of PRs merged in a given time period
Per day.
Per week.
Per sprint.
Per month.
That’s it.
No story points.
No velocity gymnastics.
Just:
How frequently are changes being merged?
That one number tells you more than you might think.
Pull request throughput is your flow rate.
When throughput is healthy:
When throughput stalls:
Throughput becomes a proxy for system health; it tells you the rate at which work is finishing.
Remember, metrics are meant to be the starting point to a conversation and not the end of the story.
Pull request throughput is not:
If you use it that way, you will destroy trust. You will see software engineers gaming the system. This metric should not be applied more granularly than at the team level.
It is good to talk to your peers and look at benchmarks related to pull request metrics for similar-sized organizations in similar sectors. However, keep in mind that pull request metrics should be interpreted in the context of your own team dynamics and project type.
It is a conversation starter, not a scoreboard.
Engineering metrics should:
Pull request throughput checks all four.
You can gather this metric easily from every major version control system.
It doesn’t require organizational transformation.
It doesn’t require elite DevOps maturity.
It doesn’t assume perfection.
It just measures whether work is flowing. And flow is where everything begins.
If you know the work is flowing, you can spend your time working with stakeholders to ensure the highest impact work is being prioritized.
First off, is it actually a bad thing if software engineers are merging code more often?
Pull request throughput should be a foundational metric you are tracking and likely something to set KPIs around. However, if you are concerned about engineers gaming the system, you can track things like pull request size as well. If the number of lines changed in a pull request drops as your pull request throughput increases, that could mean software engineers are trying to boost their numbers to hit a pull request throughput target.
As stated throughout this article, metrics should be where conversations start. If pull request throughput is increased and pull request size is decreased, it could also mean that your team is making an effort to ship smaller, more atomic units of work. That is a good thing. From my time spent as an agile coach, I learned quickly that smaller stories had a higher completion rate within a sprint than large stories with sweeping scopes. People are better at estimating smaller units of work. Smaller stories and high pull request throughput means that not only is your team's output increased, but it is also more predictable.
So efforts to "game the system" could just result in your team being more effective and doing what you have been trying to get them to do all along.
“Over the last 4 weeks, PR throughput has dropped 20%. What is going on?”
That opens a door.
You can ask:
Now imagine showing a stakeholder:
"Engineering delivery slowed this past month because we have been asking our lead engineers to pre-groom the major epics for next year."
That builds credibility.
It shows you are paying attention.
It shows you understand the system.
It shows you’re not guessing.
Metrics build trust when they illuminate reality.
Pull Request Throughput per Engineer per Month
Pull Request Throughput per Sprint
Pull Request Throughput by Repository/Service
Pull Request Throughput grouped by Pull Request Size
Pull Request Throughput by Work Type
If you believe your team's pull request throughput should be higher, the next step is to look for friction points in the development system. Your flow rate is likely being impacted by a number of small bottlenecks rather than one big one. Many enterprise teams suffer from process bottlenecks rather than technical ones.
Common places to look at are:
Throughput problems are usually system problems, not individual performance problems. Your mission is to identify where the system is slowing down your team's flow.
Many organizations overcomplicate engineering metrics. Metrics illuminate where to ask questions. Without tracking metrics, you are forced to make guesses about what is happening without data to back it up.
Track Pull Request Throughput is a simple yet incredibly powerful metric that is worth tracking. It is the simplest place to start observing flow. Your software engineering team is a system. Pull Request Throughput tells you whether work is moving. Once you measure throughput, the next questions naturally appear.
Engineering leaders who track this metric are armed with the information they need to experiment and tweak their systems and processes to improve the output flow. They have the information they need to report to stakeholders on how much work the team is delivering. It shines a light on what is actually going on with your team.
The good news is that most teams already have everything they need to start tracking it. The data is sitting in your version control system waiting for you. Aren't you curious about how work is flowing through your engineering team? Throughput tells you if work is moving. The next questions tell you why.
This is part of a series doing a deep dive into specific software engineer metrics.
Join our waitlist/newsletter and we'll send product updates and new engineering posts as they publish.