Lead Time for Changes
How long it takes your code to go from commit to production—a key indicator of delivery velocity.
Definition
Lead Time for Changes is one of the four DORA metrics. It measures the time from when a code change is committed until it's successfully running in production. This includes code review, testing, approval, and deployment phases.
Lead Time for Changes is one of two DORA "velocity" metrics (alongside Deployment Frequency). Together, they measure how fast your team can deliver value to customers.
How to Calculate Lead Time
Use median lead time across deployments. The median is more robust than average because it isn't skewed by occasional long-running changes.
Lead Time Benchmarks (DORA)
| Performance | Lead Time | What It Means |
|---|---|---|
| Elite | < 1 day | Same-day shipping capability |
| High | 1 day - 1 week | Weekly release capability |
| Medium | 1 week - 1 month | Sprint-based releases |
| Low | > 1 month | Quarterly or less frequent |
Components of Lead Time
Code Review
Time waiting for and completing code review
Optimize: Smaller PRs, review SLAs, pair programming
CI/CD Pipeline
Build, test, and deployment automation time
Optimize: Parallel tests, caching, faster runners
Manual Testing
QA and staging environment testing
Optimize: Shift-left testing, automated regression
Approval Gates
Manual approvals and change management
Optimize: Auto-approve low-risk, batch approvals
Why Lead Time Matters
- Customer value: Faster lead times mean customers get features and fixes sooner
- Competitive advantage: Ship experiments quickly, iterate faster than competitors
- Reduced risk: Smaller, faster changes are easier to review, test, and roll back
- Developer satisfaction: Seeing work go live quickly is motivating
Lead Time vs. Related Metrics
Lead Time for Changes
- • DORA metric
- • Commit → Production
- • Includes deployment pipeline
- • End-to-end delivery measure
Cycle Time
- • General engineering metric
- • Work start → Done
- • Often stops at merge
- • Development process measure
How to Reduce Lead Time
- Smaller batch sizes: Smaller PRs move faster through review and testing
- Automated testing: Replace manual testing gates with automated checks
- Faster CI/CD: Parallelize tests, use caching, upgrade runners
- Feature flags: Deploy to production before features are "done"—decouple deploy from release
- Trunk-based development: Reduce long-running branches and merge conflicts
- Reduce approval gates: Trust automation, auto-approve low-risk changes
Frequently Asked Questions
What is Lead Time for Changes?
Lead Time for Changes is a DORA metric measuring the time it takes for a code commit to reach production. It captures the entire delivery pipeline: code review, testing, staging, and deployment.
How is Lead Time for Changes calculated?
Lead Time = Time of production deployment - Time of first commit. Measure the median (not average) lead time across all deployments to avoid skew from outliers.
What is a good Lead Time for Changes?
Elite teams achieve lead times under 1 day. High performers average 1 day to 1 week. Medium performers take 1 week to 1 month. Low performers exceed 1 month.
What's the difference between Lead Time and Cycle Time?
Lead Time for Changes (DORA) measures commit-to-deploy. Cycle Time typically measures work-start-to-done (first commit to merge). Lead time is broader, including deployment pipeline time.
How do you reduce Lead Time for Changes?
Key strategies: smaller batch sizes, automated testing, faster CI/CD pipelines, parallel reviews, feature flags for decoupling deploy from release, and reducing manual approval gates.
Measure Your Lead Time
DevSpy tracks your team's delivery speed from commit to merge, helping you identify bottlenecks in your pipeline.
Start Free Trial→