PR Velocity

Overview

PR Velocity measures how many pull requests a team merges per unit of time. It is the primary throughput metric for engineering teams — separate from quality metrics like cycle time, it answers the simple question: how much are we shipping?

Velocity is most useful as a trend metric and a team comparison tool. A team's own historical baseline matters more than absolute numbers.

What is measured

Koalr counts merged pull requests per active developer per week. Opened or closed-without-merge PRs are excluded.

PR Velocity = merged PRs in period / active developer-weeks

Active developer-week: a developer is counted as active in a week if they merged at least one PR, authored any commit, or submitted any code review in that week.

This normalization allows fair comparison between teams of different sizes and accounts for PTO, holidays, and part-time contributors.

Dashboard sections

Organization velocity summary

• Median PRs/dev/week — the primary velocity KPI
• Total PRs merged in the period
• Active developer count — denominator transparency
• Velocity trend — week-over-week change

Velocity trend chart

12-week line chart of median PRs per developer per week. Shows org-level trend and optionally overlays individual team lines.

Key patterns to look for:

• Sustained increase — process improvements (CI speed, PR size reduction) are working
• Sudden drop — incident week, sprint planning overhead, or team churn
• Flat plateau — team is operating at capacity; throughput is limited by review bandwidth or WIP accumulation

Team breakdown table

Per-team velocity showing:

• PRs merged in period
• Active developer count
• PRs/dev/week (normalized)
• Trend vs. prior period (↑ / ↓ / →)

Developer leaderboard

Per-developer PR count for the period. Use with caution — this is a volume metric, not a quality metric. A developer merging 20 tiny PRs is not necessarily more productive than one merging 3 large, complex ones.

The developer table is hidden for individual contributors by default (shows only to managers and admins) to prevent misuse as a performance ranking tool.

Velocity distribution

Histogram showing how PRs/dev/week is distributed across the org. A healthy distribution is roughly normal; a bimodal distribution (some devs very high, others very low) indicates potential imbalance in task assignment.

Repository velocity

Per-repo PR velocity helps identify:

• Repos bottlenecked by slow CI — lower velocity correlates with longer CI runtimes
• Repos with high merge friction — complex CODEOWNERS rules or branch protection requirements
• High-activity repos — where most of your team's throughput is focused

Velocity vs. cycle time

These two metrics measure different things and should be read together:

Metric	What it measures	What drives it
PR Velocity	Throughput — how much ships	PR size, WIP limits, CI speed
Cycle Time	Speed — how fast work flows	Review pickup, PR size, deploy automation

High velocity with high cycle time = team is busy but work is slow to ship. Low velocity with low cycle time = team is shipping less but each item flows fast.

Setting velocity goals

Koalr lets you set team velocity targets in Settings → Work Configuration. Once set:

• Current velocity is shown relative to target (e.g., "7.2 / 10 PRs per dev-week")
• Trend indicator shows direction relative to target
• Slack digest includes velocity goal status

Velocity targets should be set based on the team's own historical baseline, not cross-team benchmarks. A platform team maintaining 6 repos will have different natural velocity than a product team working in one repo.

Relationship to other metrics

• Cycle Time — velocity and cycle time together give the full throughput picture (Cycle Time)
• PR Size Distribution — smaller PRs drive higher velocity; large PRs slow throughput (PR Size Distribution)
• WIP Limits — WIP accumulation suppresses velocity by fragmenting developer focus (WIP Limits)
• DORA Metrics — velocity feeds Deployment Frequency when combined with CI/CD automation (DORA Metrics)