PR cycle time: the dots the average hides

PR Cycle Time Scatter plots one dot per merged pull request — when it merged, how many hours it took open-to-merge, and a colour for its benchmark tier. Click any dot to drill into that author's PRs. It exists because a single median number can look fine while three PRs quietly wreck your week.

deckgauge · Board · Intelligence
EliteHighMediumLow

Cycle hours per merged PR, by merge date. Colour = benchmark tier.

What it measures, and where the data comes from

Every merged PR is one dot. X is the day it merged, Y is cycle hours — open to merge, wall-clock — and the colour is which benchmark tier that single PR landed in. Nothing is averaged away; a bad PR stays visible as a bad PR.

  • GitHub — pull requests, opened-at to merged-at, per PR.
  • GitLab — merge requests, same opened-to-merged window.
  • Azure DevOps — pull requests, same window, from the repos you've opted into code intel for.

Click a dot and it drills into that author's PRs, filtered to them — useful for confirming whether a high dot is a one-off or a pattern for that person.

How to read it

Don't start with the average height of the cloud — start by scanning for dots that don't belong. A tight, low band with a couple of amber or red dots poking above it is a healthy team with a handful of PRs that need attention, not a team with a cycle-time problem.

Then look sideways. A cluster of slow dots all landing in the same week is a different story than scattered outliers — that's a calendar event (a crunch, a release, people out), not a chronic issue. Vertical position tells you severity; horizontal clustering tells you cause.

What it tells you over time

Watch whether the cloud is drifting upward as a whole, or whether it's staying low with occasional spikes. A rising cloud is a systemic slowdown — reviews, batch size, or process debt building underneath everyone. Occasional high dots in an otherwise low cloud are usually just big PRs, and big PRs happen; the question is whether the same author or same area produces them repeatedly.

This is also the widget that catches what a weekly average trend can't: a single 200-hour PR that got merged on a Friday doesn't move a median much, but it might represent three days of one engineer blocked, or a review that got rubber-stamped out of fatigue. The scatter keeps that PR visible instead of diluting it into "the week was fine."

Example situations

1. A couple of dots way above the pack

deckgauge · PR Cycle Time Scatter

Two red outliers sitting far above an otherwise tight, low cloud.

What you're seeing: nine dots hugging a tight, low band, and two sitting way above everything else. If you only watched a weekly average, these two would barely nudge it — the median absorbs them.

How to react: click the highest one first. Nine times out of ten it's a genuinely large change — a migration, a refactor, a rewrite — that should probably have been split, or a PR that sat waiting on an external dependency (design sign-off, a blocked environment, a third-party review). Either way, find out before you assume it's a person problem.

Managerial playDon't chase the average — chase the dot. Open the outlier, read what actually happened, and only then decide if it's a pattern. If it's a giant diff, put a soft PR-size guardrail in place (a bot comment on anything over ~400 lines, not a hard block) so "just one more file" doesn't become "just one more week." If it's external blocking, that's a dependency problem to escalate, not a coding problem to coach.

2. A vertical wall of slow dots in one week

deckgauge · PR Cycle Time Scatter

A cluster of medium/low dots all merging the same week — everything else stayed fast.

What you're seeing: a wall of amber and red dots sharing roughly the same x-position, with fast, low dots on either side of it. This isn't one bad engineer or one bad PR — it's one bad week for everybody who happened to merge during it.

How to react: line the week up against your calendar before you look anywhere else. It's almost always a release freeze that backed everything up, a reviewer or two out at the same time, or a crunch where everyone was heads-down and nobody had review bandwidth left over.

Managerial playStaff reviews deliberately during known crunch or release weeks — name a rotating "reviewer of the day" whose only job that week is clearing the queue, instead of hoping it self-organizes. Spread releases out rather than batching everything into a single freeze window; a wall like this is the direct cost of a big-bang release cadence. If it's a people-out problem, build a thinner backup rotation so one absence doesn't stall a whole week's merges.

Frequently asked

What does the PR cycle time scatter show?
One dot per merged pull request: when it merged, how many hours it took from open to merge, and a colour for its benchmark tier. Clicking a dot drills into that author's pull requests.
Why use a scatter instead of an average?
Because a median can look healthy while a handful of pull requests quietly wreck a week. The scatter makes those outliers visible, which an average is specifically designed to hide.
How do I spot a crunch week?
Look for a vertical cluster of dots at unusually high cycle hours on one date range. That shape usually means a batch of work was held and merged together rather than that everything slowed down evenly.

Related widgets

Last updated