Deploy free

Lead time for changes: the trend line that tells you if shipping is getting harder

Lead time for changes is the median hours from a change's first commit to its PR or MR merging, plotted weekly. It's the one DORA key Deckgauge measures directly instead of proxying — so when this line moves, believe it.

deckgauge · Board · Intelligence

Lead time for changes, p50 by week, with benchmark bands.

What it measures, and where the data comes from

One number, one clean definition: the p50 (median) hours from a change's earliest commit to the moment its pull or merge request lands. Median, not average, so one three-week monster PR doesn't drag the whole line around.

  • GitHub — pull requests: first-commit timestamp to merge timestamp, per PR.
  • GitLab — merge requests, same first-commit-to-merge window.
  • Azure DevOps — pull requests, same window, pulled from the repos you've opted into code intel for.

Every merged change across your connected repos lands in one weekly median. No sampling, no proxy — this is the widget to trust when you need a number for a board deck.

How to read it

The shaded bands are the DORA tiers: Elite under 24 hours, High under a week, Medium under a month, Low beyond that. Look at which band the recent weeks sit in before you look at the exact hour count — the tier is the story, the number is the detail.

A flat line in a good band is boring, and boring is the goal. Watch the direction, not any single week. One bad week is noise — a bad three-week run is a trend, and trends are what you act on.

What it tells you over time

This line is a leading indicator for review health, not coding speed. Engineers rarely get slower at writing code; what changes is how long a finished change sits waiting on someone else. If lead time climbs while commit volume holds steady, the bottleneck is downstream of the keyboard — reviews, batch size, or a flaky pipeline gate.

Because it's measured (not proxied), it's also the fastest way to prove or disprove a process change. Ship a review SLA or a smaller-PR norm, then watch this line for two to three weeks. If it doesn't move, the SLA isn't the fix — go looking elsewhere.

Example situations

1. The review process is quietly slowing down

deckgauge · Lead Time for Changes

Three straight weeks climbing, commit volume flat.

What you're seeing: the line has climbed for three consecutive weeks — Elite to High to Medium — while the team's commit count didn't budge. Nobody wrote less code. Something between "done" and "merged" got slower.

How to react: don't tell people to code faster; that's not where the time is going. Pull up Review Pickup Time first — if PRs are sitting hours before anyone even looks, that's your answer. If pickup is fine but merge still lags, check PR Size Distribution for creeping batch size. Either way, this is a process signal, not an effort signal.

Managerial playAttack the wait states directly instead of asking anyone to review faster. Turn on a merge queue so an approved PR lands the moment it's ready instead of sitting for someone to notice; run a weekly stale-PR sweep and personally nudge whoever's had the oldest one assigned; and when a review stalls because it's genuinely hard, put two people in a room to pair on it rather than let it rot in a queue. If pickup time specifically is the bottleneck, the Review Pickup Time guide covers the SLA mechanics in detail — check the trend again in two weeks either way; one good week is luck, three is a fix.

2. A process change actually worked

deckgauge · Lead Time for Changes

A step down that holds, after smaller PRs became the norm.

What you're seeing: the line drops sharply around the week you introduced smaller PRs or a review SLA, and — this is the part that matters — it stays down. Not a one-week blip; a new baseline, holding in the Elite band.

How to react: this is rare enough to be worth calling out explicitly. Confirm it's real by checking that PR volume and merge count didn't just drop with it (a quiet quarter can fake a good lead-time line). If the work kept flowing and the line still fell, you have proof a specific change worked.

Managerial playName the change in the next retro, out loud, with the before/after number attached — "lead time went from 6 days to 22 hours after we capped PR size." That's what turns a one-off improvement into a norm nobody backslides on. Write the new default into the team's working agreement so it survives the next reorg or ramp-up, and resist the urge to immediately raise the bar further; let a good baseline sit for a full quarter before you ask for more.

Frequently asked

What is lead time for changes?
The median hours from a change's first commit to its pull or merge request merging, plotted weekly. It is one of the four DORA keys.
Is lead time measured or estimated in Deckgauge?
Measured directly, not proxied. It is the DORA key computed from real commit and merge timestamps, which is why a movement in this line can be trusted.
What should I do when lead time drifts upward?
Check PR size and review pickup time first. A rising lead time is far more often caused by larger batches or slower first review than by people writing code more slowly.

Related widgets

Last updated