Skip to main content
All Guides
Metrics

Stop Guessing Capacity. Your PRs Already Know

Use PR metrics to build data-driven capacity models, plan sprints realistically, and communicate engineering capacity to stakeholders.

11 min readUpdated December 9, 2025By CodePulse Team

Engineering leaders are often asked: "How much can your team deliver next quarter?" Story points and gut feelings only go so far. This guide shows how to use pull request data to build data-driven capacity models that help you plan realistically and communicate credibly with stakeholders.

Why PR Data Reveals True Capacity

Pull requests are the most reliable signal of engineering output because they represent completed, reviewed, merged work. Unlike story points (which vary by team) or hours logged (which don't correlate with output), PR metrics are:

  • Objective: Based on actual code shipped, not estimates
  • Consistent: Same measurement across teams and time periods
  • Leading indicators: Trends predict future capacity issues
  • Automatically collected: No manual tracking required

What PR Data Can Tell You

QuestionPR MetricInsight
How much can we ship?PRs merged per week/sprintRaw throughput baseline
Is throughput sustainable?Cycle time trendsRising cycle time = capacity strain
Who's contributing?Active contributorsEffective team size (not headcount)
Are we bottlenecked?Wait for review timeReview capacity constraints
Is quality slipping?Test failure rate, PR sizeRushing = future capacity drain
Identify bottlenecks slowing your team with CodePulse

Free Download: Capacity Planning Calculator (Interactive) — An interactive tool to estimate team delivery capacity using your PR data.

Key Metrics for Capacity Planning

1. Throughput: PRs Merged

The most straightforward capacity metric. Track PRs merged per time period:

  • Weekly: Best for sprint planning, shows recent trends
  • Monthly: Smooths out vacation/holiday variation
  • Quarterly: Strategic planning, executive reporting

Capacity Planning Formula

Expected Throughput = (Avg PRs/Week x Weeks) - PTO - Overhead

Calculate expected throughput by adjusting historical average for planned time off and meeting/planning overhead (~15-20%).

Examples:
Quarterly Planning
Avg PRs/week: 25, Weeks: 8, PTO weeks: 2, Overhead: 15%
= ~128 PRs
Interpretation:
Base25 x 8 = 200 PRs
- PTO200 - (25 x 2) = 150 PRs
- Overhead150 x 0.85 = ~128 PRs
Target120-130 PRs (realistic capacity)

2. Velocity Indicators: Cycle Time

Cycle time trends reveal whether your current pace is sustainable:

  • Stable or declining: Team has capacity headroom
  • Rising: Team is at or over capacity—work is piling up
  • Volatile: Inconsistent process or external blockers

See our Cycle Time Breakdown Guide to diagnose where time is going.

3. Contributor Count: Effective Team Size

Headcount doesn't equal capacity. Track active contributors:

  • Active contributor: Developer who merged at least 1 PR in the time period
  • Effective team size: Usually 70-85% of headcount due to PTO, meetings, non-coding work

Effective Capacity Check

Effective Team Size = Active Contributors (not headcount)

If you have 10 engineers but only 7 merged PRs last week, your effective team size is 7, not 10.

Examples:
Headcount-based
Devs: 10, PRs/dev/week: 3
= 30 PRs
Reality-based
Active devs: 7, PRs/dev/week: 3.5
= 25 PRs
Interpretation:
Gap17% overcommitment if you plan on headcount

📊View Capacity Metrics in CodePulse

Navigate to the Dashboard to see your capacity indicators:

  • PRs Merged: Total merged PRs with trend indicator
  • Cycle Time: Current average and breakdown by phase
  • Deployment Frequency: PRs merged per working day
  • Developers page shows individual contribution patterns

Identifying Capacity Constraints

Signs of Overloaded Teams

SignalWhat It MeansAction
Rising cycle timeWork waiting longer to completeReduce WIP, add capacity, or cut scope
Growing PR queueMore PRs opened than mergedReview bottleneck—rebalance reviewers
Increasing PR sizeBatching to reduce overheadOften a sign of process friction
Declining test pass rateRushing, cutting cornersQuality will create future capacity drain
Weekend/late commitsTeam working overtimeUnsustainable—burnout risk

Signs of Underutilized Teams

  • Very low cycle times with idle wait periods
  • PRs approved instantly with minimal review
  • Declining PR count without corresponding time off
  • High context-switching across many small tasks

Underutilization often indicates unclear priorities or blocked work rather than excess capacity. Investigate before adding more work.

Identify bottlenecks slowing your team with CodePulse

Planning with Historical Throughput

Building a Capacity Baseline

  1. Collect 6-12 weeks of data: Enough to smooth out anomalies
  2. Calculate weekly averages: PRs merged, cycle time, active contributors
  3. Note variations: What caused high/low weeks?
  4. Identify sustainable pace: The rate you can maintain without quality degradation

Adjusting for Known Factors

Capacity Adjustment Checklist

Time Off & Availability
  • Planned PTO and holidays
  • On-call rotation impact
  • Company events, offsites
Team Changes
  • New hires ramping up (expect 50% productivity for first month)
  • Departures (knowledge transfer overhead)
Project Overhead
  • Major initiatives (migrations, refactors)
  • End-of-quarter planning overhead
  • Technical debt paydown allocation

Setting Realistic Targets

A common mistake is planning to 100% of theoretical capacity. Build in buffer:

  • 80% rule: Plan to deliver 80% of historical throughput
  • Risk adjustment: Novel work takes longer than expected—add 20-30%
  • Interrupt buffer: Reserve 15-20% for bugs, support, and urgent requests

Communicating Capacity to Stakeholders

What Executives Want to Know

Translate engineering metrics into business terms:

Executive QuestionData to ShowHow to Frame It
"Can we ship Feature X by Q2?"Historical throughput + feature size estimate"Based on our delivery rate, we can ship X features of this size per quarter"
"Why is the team slower?"Cycle time breakdown, contributor trends"Review wait time increased 40%—we need to rebalance reviewers"
"Do we need more engineers?"Throughput vs demand, bottleneck analysis"We're at 95% capacity—additional scope requires headcount or tradeoffs"

Creating Capacity Reports

For regular reporting, include:

  1. Throughput trend: PRs merged over time (weekly or monthly)
  2. Velocity health: Cycle time trend (is it stable?)
  3. Utilization: Active contributors vs headcount
  4. Quality check: Test failure rate, review coverage
  5. Forward look: Known capacity impacts (PTO, initiatives)

See our Board-Ready Engineering Metrics guide for executive presentation tips.

Avoiding Capacity Planning Pitfalls

Common Mistakes

  • Counting PRs without context: A 10-line bugfix isn't equal to a 500-line feature
  • Ignoring quality signals: High throughput with rising defects is borrowing from the future
  • Planning to 100%: No buffer for surprises guarantees missed commitments
  • Static planning: Capacity changes—review monthly
  • Individual tracking: Use team metrics, not developer scorecards

Healthy Practices

  • Review capacity weekly in standups (quick pulse check)
  • Recalibrate monthly based on actual vs planned
  • Communicate capacity constraints proactively, not reactively
  • Use data to advocate for sustainable pace, not to push harder

For benchmarks on what "good" looks like, see our PR Cycle Time Benchmarks guide.

See these insights for your team

CodePulse connects to your GitHub and shows you actionable engineering metrics in minutes. No complex setup required.

Free tier available. No credit card required.