The Flashlight Metric: How Pull Request Throughput Illuminates Engineering Flow
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.
What Is Pull Request Throughput?
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.
Why this Metric Matters
Pull request throughput is your flow rate.
When throughput is healthy:
- Code is being reviewed regularly
- Changes are small enough to merge
- Work is being finished, not just started
- The team is unblocked
When throughput stalls:
- Reviews are bottlenecked
- PRs are too large
- Priorities are unclear
- Engineers are context switching
Throughput becomes a proxy for system health; it tells you the rate at which work is finishing.
Top comments (0)