Resources

Definition

The measurement of Lead Time is a key component of Lean theory. For software development, there are two parts to lead time:

• The time to design and validate a product / feature
• The time to deliver the feature

The design time is considered the "fuzzy front end" since it is difficult to estimate and outcomes are highly variable.

Delivery time is generally more predictable.

For WayFinder, we follow the measurement adopted by DORA - focusing on the delivery time. “Done” in this context means running in Production.

Classification

WayFinder calculates a classification tag for lead time to allow you to compare your performance with wider industry performance.

Classification tags are based on industry standards and DORA findings.

Measurement

• Branch time is calculated from the oldest commit on a branch to when it is merged to main. This is the most pessimistic measurement method, but encourages good practice. It is also flexible enough to support different types of working
• For teams following true Trunk Based Development, branch time may be 0.
• Release time is calculated based on the execution time for the pipeline

Challenges

Measuring lead time requires capturing information across different systems: source control and deployment process at a minimum. The workflow of the team will introduce inherent delays and complexity into the system and add challenges for measurement:

• GitFlow introduces batching of commits - multiple features are released together
• A PR workflow also introduces batching - a single PR may consist of multiple commits
• Branches, PRs and features are not necessarily 1-1 - a feature may be split into multiple PRs; a single branch/PR may include changes across a number of features
• Rebasing can re-write the source history: squashing commits for a PR mean that the changes on the branch are committed as a single change to the target branch: a new commit hash is generated for the merge; and the original commit is not part of the tree deployed to production.

Lead Time requires data from a number of sources to be calculated:

• Source Control
• Deployment Pipeline

We do not calculate Lead Time using task tracking tools because:

• Task trackers may also contain non-development activities that should not contribute to lead time
• Development practices can be inconsistent - “Done” for a task may not mean “running in production”
• There are varied tools for task trackers
• Despite potentially capturing “fuzzy front end” activities, there is no direct link to “code committed“ or “running in production”, which are key parts of the metric definition.

Q: What does “successfully running in production” mean?

A: “Successfully” means that the code has been deployed into the production environment and is visible to end users, i.e. the pipeline or deployment process has completed. This does NOT take into account:

• The suitability of the code: it could do the wrong thing
• That it is bug free, there could be either known or unknown bugs or issues running in production

Q: What is the starting date/time for Lead Time?

A: The starting date/time is the first commit on the branch that is merged into main/master that is then deployed into production.

Q: What is “branch time”?

A: “Branch time” is the time between the first commit on a new branch and the point at which it is merged into the ‘main’ branch.

Q: What is “release time”?

A: “Release time” is the time between the merge to ‘main’ branch and the successful completion of the deployment into the production environment.

Q: I’m following trunk based development; but make multiple commits locally before pushing changes. How does this affect my Lead Time?

A: Branch time is calculated based on the change set you pushed - the time from your first new commit locally, to the time you pushed to the main branch.

Q: I’m following trunk based development; and rebase changes locally before pushing. How does that affect my Lead Time?

A: Good question. Don’t be awkward! 😊 (we are working on it)