Lead Time for Changes

Lead Time for Changes: Measure the Time the Business Cares About

While DORA provides guidelines for Lead Time for Changes, organizations should strike a balance between prescriptive targets and applied targets that consider their specific circumstances, such as the complexity of their software systems, the maturity of their processes, and the skill level of their teams. An overly ambitious prescriptive target may lead to rushed deployments and increased risks, while an overly relaxed target may hinder process improvement efforts.

Measuring the lead time from commit to deployed-to-production is an interesting and useful measure, but in our experience it’s a far less useful signal than the cycle time for an issue to travel from first-in-progress to done. A ticket can be in progress for days before the first commit is written. Commit-based lead time hides this behavior. Commit-based lead time doesn’t take into consideration that multiple commits are typically made over the course of a story. If a story is in progress for 2 weeks with commits being made every day, it’s not true that the lead time for that story was the average of the lead times of all the commits - aka 1 week. Instead, it was the whole 2 weeks the story was in progress. Therefore Allstacks recommends issue-based lead times as the more valuable signal for most organizations.

Set up Lead Time in Allstacks

Allstacks has a commit-to-deploy lead time metric that can be used to measure lead time in the classic DORA way. That metric requires some configuration by Allstacks staff. The process for setting up this metric involves meeting with an Allstacks engineer to review your organization’s deployment process and identify what filtering parameters allow us to get just your deploys to production, and from there calculate the lead time for all the commits in each deploy, averaging those lead times based on the time periods you select.

To create Change Lead Time based on tickets, go to Process Health > Cycle Time. The Cycle Time metric measures the time between first-in-progress to resolved, and ignores the time tickets spend in a backlog/to-do state. Use the Advanced Filters dialog to filter out statuses and item types that aren’t relevant. These are often “won’t do” statuses and card types such as “subtasks” or types that represent non-code work. You have several options for grouping the results so that the metric provides more insight. We recommend grouping by issue type so you can see how the lead time of bugs compares to the lead time of stories, etc.

Go to Cycle Time:

Open

Enter your filters:

Open

[Optional] Group your data to distinguish cycle times of different types of work:

Add annotations that represent benchmarks or targets and add to your DORA dashboard: