Have you ever been confused about what Lead time or Cycle time means? What about Throughput or Takt time?!
I’ll share the basics here as I understand them. Also, I’ll offer another article so you can go deeper if you want :).
Lead time and Cycle time are sometimes used interchangeably; however, I find it helpful to distinguish between them. I take Lead time to mean the total time it takes a work item to pass through a system. Think of a drop of water doing the job of washing someone’s face. The lead time is the time the drop takes to get from the hot water tank, out the faucet, into the washcloth, then finally down the drain once it’s wrung out of the wash cloth. Notice Lead time does not just mean the time leading up to doing the face washing. No, it includes the time it takes to do the work AND the travel time up to it.
Cycle time is the time taken to complete an item of work. Cycle time is therefore a fraction of Lead time. In our face washing analogy, the cycle could start when the face washer turns off the faucet and end when the person wrings out the wash cloth. In between those two points, we measure Cycle time. Note: you can define your cycle many ways. I recommend define your cycle in the way that best encapsulates the work that creates business value.
Why distinguish between the two? Well, it’s very important to measure the time work takes to complete, but some people need to know more! Beyond knowing the cost of a feature, a customer wants to know what?…WHEN DO I GET IT! This is particularly important when SLA’s are in place. If you know you can release new features to your clients every 2 weeks, average cycle time is 4 days, and that it typically takes a month before new feature work makes it from the customer’s request email to the team that completes it, you could tell that customer, “We can have that to you in 6 weeks.” Note: I’m not suggesting that we hastily promise feature releases using only Lead time. Given the complexity of software development, communicating feature releases using date ranges, probabilities and prioritization trade-offs is a more honest and useful practice.
This is the rate at which work passes through a system. Put another way, it is the velocity of work being made “Done.” Think again of water flowing through a pipe. The volume of water passing through that pipe over time is throughput. Measuring this volume periodically allows us to detect changes in throughput and calculate averages, standard deviation, etc.
This is a very helpful metric to track. Stable throughput measures enable you to make forecasts about future delivery of work based on empirical data rather than complex, predictive models. Simply, if you know you did between 8 and 10 pieces of work last week 5 weeks, it is likely you will be able to accomplish the next 6 items on your list this week and somewhat less likely that you will get 10 completed, and even less likely you will get 15 completed.
This is the rate at which a system needs to complete work in order to meet customer demand. If Throughput is the rate of water passing through a pipe, then Takt time (or Takt rate) is rate at which water wants to flow through that pipe. Like Throughput, Takt time can be gauged regularly in order to understand the distance between it and average rate of Throughput. If Takt time is much higher than Throughput, then customers may be upset that they can’t get your product. Conversely, a Throughput that is higher than Takt time will result in over supply.
I have not used Takt time. Frankly, I am not sure it is a useful metric to collect for much software product development. To complete work at the rate customers ask for it would mean insane amounts of output! There always seems to be immensely more work to complete than we have time, people or money to complete. Additionally, implementing everything requested may be detrimental to the product under development. Optimizing the value in the product may mean fighting to keep a feature out of it! These things make me suspect that Takt time is a more useful metric in terms of commodity services like eye exams or hard good production environments.
Once you understand these terms, start measuring them in your team! Armed with this information, you can use Little’s Law to experiment with work in progress limits to increase your throughput, decrease lead time, etc. Also, using these measures to create a stable system allows you to use flow-based forecasting methods which have advantages over relative estimation techniques.
Here’s a helpful article that goes deeper:
What could you and your team use these metrics to accomplish?