Deploy free

PR velocity: count the bars, not your feelings about them

PR Velocity is the plainest chart on the dashboard: one bar per week, height equals merged GitHub PRs that week. No tier, no benchmark, no grade attached. Just a count — which is exactly why it's easy to misread.

deckgauge · Board · Intelligence

Merged PRs per week, 12-week window.

What it measures, and where the data comes from

The definition is deliberately narrow, and that's the point: a single, unambiguous count.

  • GitHub — every pull request with a merged_at timestamp inside the window, bucketed into the ISO week (Monday start) it merged in.
  • That's it. There's no second source to reconcile and no proxy math — a merge event either happened in a given week or it didn't.

Pick the window from 4, 8, 12, or 26 weeks. Below the chart you'll get a Total and a Peak — the fastest way to answer "is this a lot?" without eyeballing bar heights.

No tier on this oneUnlike DORA's deploy-frequency tile, PR Velocity doesn't grade itself Elite/High/Medium/Low. There's no universal "good" bar height — a five-person team and a fifty-person team both get a bar chart, and comparing the two numbers directly tells you nothing.

How to read it

Ignore the absolute height. What matters is the shape across weeks: flat is fine, a gentle wobble is fine, and a single tall or short bar next to otherwise-even neighbors is usually just a normal week doing normal-week things. The chart only starts telling you something the moment several bars in a row move the same direction.

Pair it with the Total and Peak numbers before you react to any one bar. One week under the peak doesn't mean much on its own; several weeks in a row sitting well below it does — that's when the peak stops being a number in the corner of the chart and starts being the standard you've quietly stopped hitting.

What it tells you over time

This chart answers exactly one question well: is work reaching the trunk at roughly the same rate it used to? It answers almost nothing about why. A falling bar height could mean bigger PRs (fewer, larger changes), a slower review process (finished work stuck, not merging), fewer people (a real headcount change), or a genuinely slower team. The bars don't tell you which — they just tell you to go check.

Example situations

1. A sustained, multi-week drop

deckgauge · PR Velocity

Bars stepping down and staying down for four straight weeks.

What you're seeing: four solid weeks, then a step down that holds for four more. Not a dip — a new, lower normal, at least so far.

How to react: resist the instinct to send a message asking for "more PRs." That treats the symptom and skips the diagnosis. Go find the actual constraint: check PR Size Distribution for creeping batch size, Review Pickup Time for a stalling review queue, and Work in Progress for too many things open at once and nothing finishing.

Managerial playName the suspected constraint out loud in the next standup and ask the team to confirm or correct it — they usually know exactly where the friction is before you do. Fix the actual bottleneck, whatever it turns out to be, instead of pushing harder on the metric itself. Demanding "more PRs" as a target just teaches people to split real work into meaningless PRs, which makes this chart look better while making almost everything else worse.

2. A one-week spike or dip that lines up with the calendar

deckgauge · PR Velocity

One low week around a public holiday, otherwise steady.

What you're seeing: one short bar sitting between two otherwise-ordinary weeks. Nothing before it or after it moved.

How to react: check a calendar before you check the team. A public holiday, a company offsite, a release freeze, or a chunk of the team being out at once will produce exactly this shape — one bar down, immediate recovery. That's context, not a signal about how the team is doing.

Managerial playKeep a lightweight log of known calendar events (holidays, freezes, offsites) next to your intelligence dashboard so a one-week dip explains itself in five seconds instead of triggering a Slack thread. Don't retro a single low bar — retro a trend. If the same week type dips every quarter (say, every release-freeze week), that's worth planning around, but it isn't worth an emergency reaction the first time you see it.

Frequently asked

What does PR velocity count?
Merged GitHub pull requests per week, one bar per week. There is no tier, benchmark or grade attached — it is a plain count.
Why does PR velocity have no benchmark?
Because a pull request is not a fixed unit of work. Comparing a raw count against an external standard would reward splitting work into smaller pieces rather than delivering more of it.
How do I read a drop in PR velocity?
Distinguish a sustained decline from a one-week blip. A single low week is usually a holiday or a large piece of work still in flight; several consecutive low weeks is worth investigating alongside cycle time.

Related widgets

Last updated