Lead Time for Changes

The time from idea to prod is where you win or lose.

Idea captured

Work started

PR opened

PR merged

Deployed to prod

Calculate Reset Copy result

Leave any field blank to skip that stage.

How this is calculated

The calculator subtracts each stage from the next.

• Backlog dwell: idea captured to work started
• Dev time: work started to PR opened
• Review dwell: PR opened to PR merged
• Deploy dwell: PR merged to deployed

Total lead time is idea to deploy. Stages without both endpoints filled in are skipped. Shares are each stage divided by total lead time.

Why this matters

Teams that only measure cycle time (dev start to merge) are looking at the middle of the pipe. The ends usually hurt more. A ticket that sits in the backlog for six weeks, then gets coded in a day, is not a fast team. It is a team with an expensive dwell problem that never shows up in the sprint retrospective.

Review dwell is the most common surprise. When a PR sits open for three days waiting on a review, every minute of that is lead time. Nothing is improving, and context is decaying.

What to do next

• Run this on your five most recent shipped changes, including the sleepers. Averages lie. The p75 tells the truth.
• If review dwell is the biggest stage, look at reviewer load and PR size before process. Reviewers drown in giant PRs.
• If backlog dwell is the biggest stage, the real problem is upstream of engineering. Product and leadership are sitting on decisions.
• If deploy dwell is significant, that is the cheapest thing here to fix. Automate the last mile.