Deploy free

PR cycle time trend: don't panic over one bad week

PR Cycle Time Trend is a weekly line: median hours from a pull request opening to it merging. There are no colour bands here to tell you Elite from Low — just the shape of the line itself, week after week, telling you whether shipping is getting harder.

deckgauge · Board · Intelligence

Weekly p50 open-to-merge hours, 12-week window.

What it measures, and where the data comes from

One number a week: the median (p50) number of hours a merged pull request spent open before it merged. Median, deliberately — a handful of week-long PRs shouldn't be able to drag the whole line around, so this widget doesn't let them.

  • GitHub — merged pull requests only, timed from when the PR was opened to when it merged, grouped into the ISO week (Monday start) it landed in.
  • Weeks with no merges plot no point — an empty week isn't zero hours, it's missing data, and the line treats it that way.

This is a close cousin of Lead Time for Changes, and worth telling apart clearly: Lead Time starts its clock at the first commit, while this widget starts at PR open. If your team opens a PR early and pushes commits into it over days, the two lines will diverge — and that gap is itself informative.

No bands, on purposeThis widget skips the Elite/High/Medium/Low bands you'll see on Lead Time for Changes. Judge it against its own recent history, not an external tier — a team that's always run at 40 hours isn't "failing" some universal standard, it's just establishing its own baseline.

How to read it

Trace the line's direction across the full window before you fixate on its current position. A flat line — even a flat line sitting fairly high — is a stable process. A line with no clear direction, wobbling within a band, is also fine; that's just week-to-week variance, not a trend.

What earns your attention is a consistent slope in one direction across three or more consecutive weeks — not the level of any single point. A week that jumps by itself gets forgotten by the next data point; a slope holding for most of a month doesn't, and it usually has a specific, findable cause upstream.

What it tells you over time

This line moves for reasons that live between "PR opened" and "PR merged" — review pickup, reviewer availability, merge-queue congestion, or PRs simply growing in scope after they're opened. It rarely moves because people started writing code more slowly; that part of the process isn't what this widget is timing. Treat a rising line as a prompt to look at the wait states, not at how hard anyone is working.

Example situations

1. The line climbs for several weeks straight

deckgauge · PR Cycle Time Trend

A steady climb over five weeks, no single outlier driving it.

What you're seeing: a consistent upward slope, week over week, with no single spike doing the damage — every week is a little worse than the one before it. That pattern is what separates a real trend from bad luck.

How to react: this is the signature of PRs taking longer end to end, not any one PR going wrong. Go looking for where the wait is actually happening before you assume it's review speed — it might just as easily be PR size creeping up.

Managerial playAttack the wait states directly instead of asking people to "move faster." Start with the Review Pickup Time guide — if PRs are sitting untouched before anyone even looks, that's usually the biggest single lever, and it has a concrete SLA-based fix. If pickup is fine and PRs are just taking longer to fully approve, check whether a merge queue would help clear the backlog faster than people can manually. Re-check this line in two to three weeks either way — a fix that doesn't move it wasn't the fix.

2. A single-week spike that's really one or two PRs

deckgauge · PR Cycle Time Trend

One week jumps, then the line drops right back to baseline.

What you're seeing: the line jumps sharply for exactly one week and then falls straight back to where it was. The median moved, but the surrounding weeks look untouched.

How to react: don't call an all-hands over one bad point. A median can still get pulled around by a small number of unusually large PRs merging the same week — that's precisely what this chart can't distinguish from a real, broad slowdown on its own.

Managerial playClick into PR Cycle Time Scatter for that same week before drawing any conclusion — it'll show you whether it was one or two outsized dots or a genuine wall of slow PRs. If it's a couple of big migrations or refactors, that's a one-off, not a process problem. If the scatter shows a broad cluster, you've actually found the start of case one above, just one week earlier than the trend line would otherwise reveal it.

Frequently asked

What does PR cycle time trend measure?
The weekly median hours from a pull request opening to it merging, plotted as a line. There are deliberately no benchmark bands — only the shape of the line over time.
How do I tell a real slowdown from one outsized PR?
Check the PR Cycle Time Scatter for the same period. If one or two dots sit far above the rest, the median moved because of them; if the whole cluster shifted upward, the slowdown is genuine.
Why are there no Elite or Low bands on this widget?
Because open-to-merge time varies too much between teams and problem types for a universal tier to be honest. The trend against your own history is the meaningful comparison.

Related widgets

Last updated