Standard : Lead Time for Change

Description

Lead Time for Change (LTFC) is a key DORA metric that measures the time it takes for a committed code change to be deployed into production. It reflects the speed and flow of your software delivery pipeline—from development through to live customer impact.

Shorter lead times signal healthy automation, reliable pipelines, and low delivery friction. This metric is an essential indicator of engineering agility, responsiveness, and continuous improvement.

How to Use

What to Measure

  • The elapsed time between a code commit (e.g. PR merge) and successful deployment to production.
  • Optionally track by team, service, or type of change (feature, fix, config).

Formula

Lead Time for Change = Deployment Timestamp – Commit Timestamp

Instrumentation Tips

  • Integrate VCS (e.g. GitHub, GitLab) with CI/CD tools to collect timestamps.
  • Use tagging or labeling to distinguish production deployments.
  • Visualise LTFC trends in dashboards and include outlier detection.

DORA Benchmarks

Performance Level Lead Time for Change
Elite < 1 hour
High < 1 day
Medium 1 day to 1 week
Low More than 1 week

Why It Matters

  • Speed to value: Reduces the time between idea and user impact.
  • Flow efficiency: Reflects pipeline and process efficiency.
  • Feedback loops: Enables teams to learn faster from changes.
  • Competitive advantage: Supports rapid experimentation and innovation.

Best Practices

  • Use trunk-based development with short-lived branches.
  • Automate tests and deploy steps with CI/CD pipelines.
  • Monitor and improve pipeline duration and queue times.
  • Reduce WIP (Work In Progress) and handoffs across roles.
  • Align delivery cadence with product and customer feedback loops.

Common Pitfalls

  • Measuring from ticket creation instead of code commit.
  • Counting only successful changes (exclude aborted PRs).
  • Ignoring context: high lead time may be valid in regulated systems.
  • Over-optimising speed without maintaining reliability.

Signals of Success

  • Engineering and product teams see value shipped daily or weekly.
  • Pipeline time is predictable and visible to engineers.
  • Code spends minimal time idle between stages.
  • Time from customer insight to implementation is shrinking.
  • [[CoE/Measures/Delivery Performance/Deployment Frequency]]
  • [[Change Failure Rate]]
  • [[Mean Time to Recovery (MTTR)]]
  • [[Time to Value]]