paint-brush
Why You Should Use Lead Time Instead of Cycle Timeby@george-guimaraes
143 reads

Why You Should Use Lead Time Instead of Cycle Time

by George GuimarãesJanuary 18th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

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. Using Throughput or other measurements of deliveries over time, I very much prefer using Throughput to give everyone a better understanding of lead time. I think you should not use cycle time when referring to single items and how many days that item is in the process flow.

Coin Mentioned

Mention Thumbnail
featured image - Why You Should Use Lead Time Instead of Cycle Time
George Guimarães HackerNoon profile picture

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.

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