In the fast paced world of product development, getting a grip on Key Metrics like Cycle Time and Lead Time can make a significant impact in how smoothly and quickly you can roll out new features and updates into Production.

In this blog post, we will be breaking down what these metrics refer to, the importance of distinguishing between them, and why they matter. Plus, we’ll look at a real-life Agile Example by extracting the necessary metrics when a distinction is made between the two. There is always an opportunity cost when metrics are conflated, and we will be discovering that by an example in hand.

The Confusion

There is no consistency between how people distinguish between Lead Time For Change, and Cycle time. Both Metrics are used synonymously, and that is exactly where misalignment begins. What might be considered lead time for one developer is, in reality cycle time, and vice versa.

Lets take some online references from the Web, and notorious organisations providing a service in Tech.

Atlassian’s Vs Agile Academy take on Lead Time For Change

Atlassian makes it crystal clear that Lead Time for Change, is tightly coupled with Software Development – from commitment to deployment. hey emphasise this by highlighting how both development and QA work can improve this metric by suggesting more code reviews, automated tests, and triggers.

“Lead time for changes measures the average speed at which the DevOps team delivers code, from commitment to deployment. It indicates the team’s capacity, the complexity of the code, and DevOps’ overall ability to respond to changes in the environment.

This metric helps businesses quantify code delivery speed to the customer or business. For example, some highly skilled teams may have an average lead time of 2-4 hours for changes, whereas for others, it may be a week.

Reducing the amount of work in the deployment, improving code reviews, and increasing automation can help reduce lead time for changes.”

The above description, contradicts both wikipedia (that’s OK for us, as wikipedia should never be used as the only source of truth), and Agile Academy – this is where we raise an eyebrow.

“The Lead Time measures the time from the moment the customer makes a request to the time they receive something. The Cycle Time measures the time it takes the development team to work on the request and deliver it. This means the Lead Time includes the Cycle Time .“

Notice the misalignment in the term Lead Time For Change, where as per Agile Academy, distinguishes between both, by separating concerns via development Work.

Keeping into consideration the above confusion, we like Martin Fowlers approach in distinguishing between the two by making specific reference and distinction between an Idea, and the development of the Idea. Here are also some questions that led us towards redefining these 2 metrics:

Q: How long will it take for my Idea to be tangible in production?
A: Idea Cycle Time

Q: How long will it take me to build the idea?
A: First-Commit Cycle Time

Standard	Refined
Lead Time For Change Cycle	Idea Cycle Time
Cycle Time	First-Commit Cycle Time

A real-life agile example

Lets discover the importance of why it is important to distinguish between the two. Lets take into consideration the below agile team dynamics:

An Agile Team (Product Owner, 3 Developers and a QA Engineer), having daily stand-ups, a weekly backlog refinement and a by-weekly Sprint planning session and a sprint retrospective session – happening by the end of the sprint.

The team is responsible in delivering features for a set of both back-end and front-end microservices, every 2 weeks (1 sprint is 2 weeks long)

Agile ceremonies are part of the sprint, thus, in every sprint there is time allocated for both a weekly Backlog Refinement session, a Sprint planning session and a Sprint retro session.

Caveat: Every team member (not just the Product Owner) has the authority and ability to insert ideas / features within the products backlog.

Based on these Sprint Activities, we can measure properly Idea Cycle Time and First-Commit Cycle time. The diagram below illustrates the difference between both.

Idea Inception
At this stage, the idea is filed as a Feature Request within the Product Backlog. The Product backlog is a list of tasks for the agile team, in the form of either bug fixes or feature requests, waiting to be inserted into a sprint.
If it is not documented, it does not exist. Documentation is crucial, as it is the starting point for the Idea Cycle Time Metric.

Product Backlog Refinement
This is were the team will pick up the Feature Request and starts to refine it. There are 2 paths for the feature request from here:
– Either it will be dumped.
– Or it will be refined and planned to be developed.

This suggests a number of metrics to track, labeled in the diagram as Metrics Set A

Metric 1: Mean Time Lapsed from Idea Inception to Backlog Refinement.
Value: How long does it take to for suggested features to be looked at and refined?

Metric 2: Number of Suggested Features Kept vs Number of Suggested features Dumped
Value: How much familiar is the team with Product? If a substantial number of suggested features (substantial converts to 80%) are being rejected, than it might be the case where the team needs more domain knowledge, or exposure of what the customer needs / wants.

Sprint Planning
If the feature made it to this stage, then it means that the suggested feature request, the idea, made it towards development, thus, included within the sprint.

A valuable metric – labeled as Metric B, is to measure the Time it takes for a suggested feature which is approved and aligned with the business, to start actual development on it. The value of measuring such metric is to address the features’ priority. What was the opportunity cost of having such a valuable feature delayed by x amount of time?

CICD – Actual Sprint
This is the stage where Development Starts. LTFC as per Atlassian, and Cycle time as per Agile Academy. This is where First-Commit is measured. Metric C deals purely with the time taken for an idea to be developed, or better, for a Feature Request to be converted into code.

Conclusion

Understanding and distinguishing between Lead Time for Change and Cycle Time is vital for any agile team aiming to optimize its development processes. By breaking down the journey from idea inception to actual deployment, we can better track and improve how efficiently we bring new features and fixes to our product.

So next time someone asks you whats the difference between the two, make sure you understand how that individual is making the distinction.

References:
https://www.atlassian.com/devops/frameworks/dora-metrics
https://www.agile-academy.com/en/agile-dictionary/lead-time-vs-cycle-time/
https://martinfowler.com/bliki/CycleTime.html