Lead time is defined by the amount of time each item takes to pass through the entire process or through only a specific step. So, it’s ok to have several lead times, each serving to a different purpose, each for a different metric or indicator.
end_date - start_date
and probably truncating to days or hours, depending on the process you want to monitor.
Cycle Time is defined as the time between the output of two successive units of work in a process.
So, it resembles a measurement of frequency. Think “looking at this step, how many items come through in a period?”.
However, given the definition, cycle time is measured as the inverse of frequency. So, when we say cycle time of 1 day, it means that, after one delivery, the next one will be delivered (on average) in 1 day.
I’m not keen on using cycle time. Since so many people don’t know its meaning, I very much prefer using Throughput or other measurements of deliveries over time.
But, there’s one metric that we use in Software Engineering that resembles cycle time: frequency of deploys. When we say “we deploy 12 times per day”, we could also say, “on average, there’s a deploy coming every 2 hours.” I know, not usual to speak that way, but that’s how cycle times would work if we use the original semantics from Operations Management.
My take on this
I think you should not use cycle time when referring to single items and how many days that item is in the process flow. That’s the definition for lead time!
However, that’s not how the Agile community has been using lead times and cycle times, leading to a whirl of confusion.
So, my tips for anyone measuring software engineering:
- Use Lead Times to describe how much time has passed for an item in the process. You can also use averages and percentiles when aggregating individual lead times.
- Don’t use Cycle Times. Using Throughput should give everyone a better understanding.
And you, what terms have you been using?
Previously published at https://sourcelevel.io/blog/why-you-should-use-lead-time-instead-of-cycle-time