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.
Median is reported alongside the average to avoid outlier distortion. P75 and P90 percentiles surface the slow-tail.
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
Look at median first — averages get pulled by long-tail PRs.
Compare median vs. P90. 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