Lead Time for Changes measures the elapsed time from a code change to its production deployment. It tells you how long an idea takes to reach customers once a developer starts work.
What it measures
The duration between commit (or merge, depending on your source-of-truth choice) and successful production deployment, computed per change.
How Leanmote calculates it
lead_time_for_change = deployed_at - commit_or_merge_at
Computed per change unit — commit, PR, or merge.
One statistic at a time, chosen with the method selector — they are not shown side by side. The default is the average. The other options are the median, the P75, P85 and P95 percentiles, and the standard deviation; there is no P90.
Optional decomposition lets you isolate where time goes:
coding_time = first_commit_at - issue_started_atreview_time = merged_at - opened_atrelease_wait_time = deployed_at - merged_at
How to interpret it
Switch to median first — the default average gets pulled by long-tail PRs.
Then read P95 and compare it against the median. A wide gap means most changes are fast but some are stuck for days. Investigate the slow ones.
If decomposition is available, the largest sub-duration (review, coding, or release wait) tells you where to invest improvement effort.
What to do about it
If review time dominates: reduce reviewer load, set a review SLA, or use working agreements.
If coding time dominates: shrink stories, slice work earlier, or address scope creep.
If release wait time dominates: deploy more often, automate gates, or move from batched to continuous deploys.
Related metrics
Deployment Frequency
Cycle Time
Review latency
DORA metrics overview