Documentation menu
Lead time for changes
What it is
Lead time for changes is one of the four DORA metrics. It measures how long it takes for code to go from committed to successfully running in production, covering everything in between: review, merge, build, test and deploy.
Two related measures look further back:
- Cycle time: from the moment work starts on a ticket (it moves to In Progress) until the change is in production.
- Lead time: from the moment a ticket is created until the change is in production.
Reading it
A short lead time means a team can deliver changes quickly and get feedback early. A long one usually hides waiting: for review, for a release window, for a runner. Lead time is best read next to deployment frequency and the change failure rate: speed at the cost of stability is not an improvement.
Performance tiers
| Tier | Lead time for changes |
|---|---|
| Elite | Less than one day |
| High | Between one day and one week |
| Medium | Between one week and one month |
| Low | Between one month and six months |
In Agile Analytics
Lead time for changes is measured from the merge into the main branch until the production deployment that carried the change. Cycle time and lead time need Jira: the ticket key in the branch name or merge request links the change to its ticket. All three are shown on the DORA metrics page; the health score rates delivery on cycle time, so it reflects the whole flow from start of work to production. The CI queue time card shows one hidden part of the lead time: how long jobs waited for a runner.
