Our concepts of Lead Time and Cycle Time came from the field of Operations Management and Production Engineering. As such, I think it’s beneficial to all of us to maintain coherent with them and use the same semantics in Software Engineering Management as well.
Lead Time
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.
Usually, that means it is as easy as end_date - start_date and probably truncating to days or hours, depending on the process you want to monitor.
Cycle Time
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.
See our Data & Analytics Platform Live: Click here to get a full demo of SourceLevel Engineering Metrics and how they can help your team.
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?
Co-founder and CEO of SourceLevel. Previously co-founder of Plataformatec.
Loves to talk about software engineering, Elixir, coffee, mechanical keyboards, multitools and his 3 big dogs.