How Do You Measure Lead Time for Changes?
One of the most common questions teams encounter when implementing DORA metrics is surprisingly simple:
How do we measure Lead Time for Changes if our team uses squash commits?
The concern is understandable. Traditional descriptions of DORA often refer to measuring the time from a code commit until that change reaches production. But modern development teams frequently use Pull Requests and squash merging strategies that remove individual commit history from the main branch.
Fortunately, squash commits do not prevent accurate DORA measurement. In many cases, they actually encourage a more meaningful approach.
A Quick Refresher: What Is Lead Time for Changes?
Lead Time for Changes measures how long it takes a code change to move from development into production.
The metric helps answer:
- How quickly can we deliver value?
- Where are bottlenecks occurring?
- Are reviews, testing, or deployments slowing us down?
The DORA framework identifies Lead Time for Changes as one of four key indicators of software delivery performance:
- Deployment Frequency
- Lead Time for Changes
- Change Failure Rate
- Mean Time to Restore (MTTR)
Of these, Lead Time is often the most difficult to calculate accurately.
The Challenge with Squash Commits
Consider a typical workflow:
After the PR is merged, the main branch contains a single commit representing the entire feature.
If your DORA implementation relies solely on Git commit history, you lose visibility of:
- When the work started
- How long the PR was under review
- How long the changes waited before deployment
Measuring from the squash commit to production can produce misleadingly optimistic results.
Example:
The metric suggests exceptional performance while ignoring seven days of actual delivery effort.
What Should Count as a "Change"?
The answer lies in redefining what constitutes a change.
In modern development workflows, the Pull Request is often a more meaningful unit of change than an individual commit.
A Pull Request represents:
- The complete scope of work
- Review activity
- Quality checks
- Approval workflows
- A deployable feature or fix
For many organizations, the Pull Request becomes the ideal object for DORA measurement.
Option 1: PR Creation to Production (Recommended)
This is the approach most organizations should adopt.
Lead Time is calculated as:
Why This Works
This approach captures the entire delivery process:
- Development activity
- Review delays
- Build and testing time
- Release management overhead
- Deployment execution
It answers the business question DORA is designed to measure:
How long does it take to turn a completed piece of work into customer value?
Example
Option 2: First Commit in the PR to Production
Some teams prefer to include active development time.
Calculation:
This aligns more closely with the original DORA concept of measuring from code creation to deployment.
Advantages
- Captures coding effort
- Includes review and release latency
- Maintains compatibility with DORA research
Considerations
Developers may create early "work in progress" commits long before meaningful development begins.
This can inflate lead times and create volatility in the metric.
Option 3: Merge to Production
Some tools default to measuring from the merge commit.
Calculation:
This metric is easy to obtain but should not be considered your primary DORA lead time measurement.
It only measures release pipeline efficiency and ignores:
- Development work
- Review cycles
- Approval delays
At best, it is a supporting metric.
The Most Useful Approach: Measure Two Lead Times
Mature engineering organizations often track two separate metrics:
Delivery Lead Time
This reflects overall software delivery speed.
Release Lead Time
This reflects deployment and release process efficiency.
Having both metrics helps identify where delays occur.
For example:
| Metric | Result |
|---|---|
| PR → Production | 8 days |
| Merge → Production | 4 hours |
This suggests the deployment process is healthy while development and review workflows deserve attention.
Conversely:
| Metric | Result |
|---|---|
| PR → Production | 2 days |
| Merge → Production | 5 days |
This suggests engineering throughput is strong, but releases are waiting too long to reach customers.
Data You Need
Regardless of merge strategy, the following data is usually sufficient:
Pull Request Data
Deployment Data
Optional Commit Information
Most of this information is already available in:
- GitHub
- Azure DevOps
- GitLab
- Bitbucket
- Jenkins
- Azure Pipelines
- GitHub Actions
Azure DevOps Example
A common Azure DevOps workflow looks like this:
In this model, Lead Time can be calculated as:
No dependency exists on preserving individual commit history.
Final Thoughts
Teams often worry that squash commits make DORA metrics difficult to implement. In reality, they encourage a healthier measurement approach.
Rather than treating individual Git commits as the unit of delivery, focus on the Pull Request as the change artifact.
If your team uses squash merges, the most practical and meaningful definition of Lead Time for Changes is:
Time from Pull Request creation to successful deployment into production.
This captures the complete delivery process, remains robust regardless of merge strategy, and provides actionable insights into how quickly your organization turns code into customer value.
Ultimately, DORA metrics are not about measuring Git history. They are about measuring delivery outcomes. The closer your implementation reflects the real flow of work, the more valuable the metric becomes.
No comments:
Post a Comment