Cycle-time and Lead-time and even Little’s Law are terms that have migrated over into the software development context and are becoming more widely used, but I am not sure they are fully understood so I’ll attempt to clarify my understanding of the terms.
How does cycle time differ from lead time?
There are two different ways I have seen to express Cycle-time:
“Cycle Time” is the overall amount of elapsed time taken to create an item. Measured from the point when work starts until item is delivered.
“Cycle Time” is the average amount of time between each delivered item. e.g. 7 items delivered in a week is a cycle time of 1 day
Lead-time seems to be consistent
“Lead Time” is the amount of elapsed time from which the order was first requested by the customer until the customer has received it.
Note: The different uses of cycle time cause confusion and I prefer the first description in a software context, as the second one ignores the impact of WiP.
Clearly both of these are more complicated in software terms as the boundaries are not as clear.
Cycle-time is generally considered to be the point when a backlog item is committed and the item is “in progress” through our development cycle, in Kanban terms this is likely time counted from when it moves out of the ‘backlog’ column. We stop counting when it is moved to the ‘done’ column. There can be a whole debate about what ‘done’ means and that is for another topic. But for simplicity the ‘cycle’ ends when your team will stop work on it (ideally it will be in the hands of the customer).
In Scrum cycle-time is typically fixed at a sprint length, we commit at the start of the sprint and deliver at the end. But that is not universally true, some teams do not always deliver and there will be effort later to deploy as part of a scheduled release, and some teams deliver as soon as a story is complete.
Note: Cycle-time is sometimes called delivery time. But again this get confused with lead-time because of the non-linear manufacturing to software conversion.
Lead-time is a bit more complicated, it may be counted from the point a need is first identified by a customer to when it is resolved but this is rarely a one-to-one mapping, or it may be considered from the point when the need is identified and refined into a backlog item that will be worked on and delivered.
But really for agile backlogs we generally don’t work in a linear fashion, just because a request has been on the backlog longer doesn’t mean it will be delivered sooner. We prioritize and so a request identified last week may be delivered sooner than one from last year.
As a result Lead-time is generally not used as frequently as Cycle-time, not because we can’t measure it but because it is not as meaningful or useful.
Another often used term is “Throughput” this is simply the number of units that have passed though the system (units completed) in a given period. e.g. Our throughput is: 10 stories per week, or 5 customers per hour.
Unless stated otherwise you can usually assume that it is an average (mean) or the most recent time period.
Cycle time is a trailing measurement and we are able to come up with metrics and averages from historic results. But a mathematician from MIT – John Little devised a mathematical formula for predicatively calculating Cycle-time from the number of units in the system.
Average Cycle Time = Average Number of items in progress / Average Throughput
Projected Cycle Time = Number of items currently in progress / Average Throughput
e.g. So let’s say you have 50 items in progress and on average you complete 10 per week.
Number of items currently in progress (50) / Average Throughput (10 per week)
Projected Cycle Time: 50/10 = 5 weeks
What this tells us is that for the new units entering the system, on average it will be 5 weeks before each of them is completed.
If we want to reduce Cycle-time we have two options we can either reduce the amount of work in progress, or we can increase throughput. Often our throughput is limited by other factors and so may be harder to change, such as team size or equipment availability. But work in progress (WiP) is typically more within our discretion.
Lets say we reduce the work in progress to just 20.
Number of items currently in progress (20) / Average Throughput (10 per week)
Projected Cycle Time: 20/10 = 2 weeks
What this tells us is that for the new units entering the system, on average it will be 2 weeks before each of them is completed.
What you see here is that our throughput is the same, we are still delivering the same amount but by reducing work in progress we are able to deliver the same amount in a shorter elapsed time, and in a desire to have more agility then a shorter cycle time enables us to change direction sooner. Less work in progress does not increase our throughput, however, it makes us more dynamic and more adaptable to change.
The less work you have in progress the sooner it will get done.
In essence – the less work you have in progress the sooner it will get done, that is the lesson that should be taken from this.
But there does become a point where you can reduce the work in progress to a point where throughput is impacted (the system can become starved) and thus there is a trade-off.
In some situations cycle-time is a critical factor so an element of slack time is desirable, say urgent need to see a doctor, compared to a regular appointment.
But in most other cases we would aim to limit our WiP as much as we can to the point where throughput is not impacted.
Other less used terms
Then we come to the fun ones, these terms come from manufacturing but are used much less frequently in a software context but may be useful to be aware of as it can help understand the composition of cycle-time and where you can take action to tighten up your process.
- Process Time
- This is the time when someone is working on creating something: writing code, documents, design, tests, etc.
- Move time
- In software terms this would the time to move from one user to another or from one action to another and so would include, compilation, building, deploying and hand over/knowledge sharing
- Inspection time
- This might be QA time or code reviews, demonstration to Product Owners or stakeholders, but this may overlap with process time as this is still value added work.
- Queue time
- This is time when a unit(story/task) is in progress but no worked on, say blocked, or waiting to be code reviewed waiting for QA waiting for Demo, any time work is paused for any reason before it is done.
- Wait time
- This is the time a request spends in the backlog before we commit to work on it, e.g. the time from when a customer identifies a feature/function or bug until we start work on it.
- Value added time
- Any time in the system where activity that adds value is happening e..g not queuing, waiting.
Cycle-time and Little’s Law are becoming much more frequently used and whilst they are not complicated to understand the basics of they do bring a new set of terms and associated confusion.
For example I have seen a number of times recently people advising that reducing cycle-time increases throughput. Mathematically speaking this is incorrect, (although the reverse is true increased through put should reduce cycle-time). Anecdotally less context switching does increase throughput.
What they are advising is good advice – reduction of Work In Progress. However, their expectation and reasoning is wrong and adds to yet more confusion.
Cycle-time is not a measure of quantity of output, but a measure of the duration it is in the system. It is important to remember that throughput and cycle-time are different measures.
Cycle-time is not a measure of quantity of output, but the duration it is in the system.
I hope this helps and I’d be happy to add any further clarification if there are parts that are unclear.