Throughput, Story Lead and Cycle Time are the frequently used Kanban metrics. These were defined for deliverable of same size and equal priority. But a software support team deals with incidents of different size and variable priorities. Hence, Kanban metrics collected without considering these factors (Size and priority) don’t deliver the purpose.
Illustration for cycle time and size of delivery: "Cycle time" is the time it takes to complete the production of one unit from start to finish. However, software support teams don’t have the luxury of working on issues of same size, unlike the mechanical production lines.
For example,
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents then the average cycle time is 2.
Day 2:
Again, the Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 medium incidents; even then the average cycle time is 2.
Now, the production line has spent equal amount of effort on both the days and has delivered equal value; and the metrics shows it correctly. On the other hand, the support team has spent more effort and has delivered higher value on the second day. But the metrics shows the same number, and hence it is not adequate to reflect the value delivered.
Solution: Normalizing the size of the incident could be a solution which is practically impossible. So, we can provide weightage to the incidents.
To illustrate:
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents. Weightage for small incidents are 1. Hence 8/(4*1) = 2 is the average cycle time.
Day 2 :
The second days, Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time, a support team takes 8 hours to deliver 4 medium incidents. Weightage for medium sized incidents are 2. Hence 8/(4*2) = 1 is the average cycle time.
This reduction in the cycle time shows the higher productivity. This is a dependable metrics.
Illustration for lead time and priority: "Lead time" is the time it takes for one unit to make its way through operation from taking the order to delivery. This definition assumes that all deliverable are of same priority. However, the software support works on priority. And we ‘park’ the low priority incidents when relatively higher priority come into the queue.
So, to illustrate,
Consider three incidents A, B and C and all are of same size and came to the backlog at same time.
A came to the queue first and was delivered in 3 hours. Lead time for A is 3 hours.
B is of low priority where C comes with high priority. Hence, we park B and take C next to deliver in 3 hours. Now the lead time for C is 6 Hours. Now, B is brought from parking to delivery queue. Which has a waiting time of 6 hours. Now B is delivered in 3 hours. Hence the Lead time for B is 9 Hours.
Now, we should be able to distinguish the time spent in backlog and the time spent in parking. Because the lead time is going to be used in discussing the backlog health.
So, the time spent in parking should be offset, so that we would be able to see the correct scenario. In the example above,
Lead time for A – 3 hours.
Lead time for B is 9 – 3 (parking hours) = 6 hours
Lead time for C is 6 Hours.
Conclusion:
Hence, for both cycle time and Lead time, the time spent in parking should be deducted before calculation.
And for cycle time the incidents should be given weightage before calculating the cycle time.
Illustration for cycle time and size of delivery: "Cycle time" is the time it takes to complete the production of one unit from start to finish. However, software support teams don’t have the luxury of working on issues of same size, unlike the mechanical production lines.
For example,
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents then the average cycle time is 2.
Day 2:
Again, the Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 medium incidents; even then the average cycle time is 2.
Now, the production line has spent equal amount of effort on both the days and has delivered equal value; and the metrics shows it correctly. On the other hand, the support team has spent more effort and has delivered higher value on the second day. But the metrics shows the same number, and hence it is not adequate to reflect the value delivered.
Solution: Normalizing the size of the incident could be a solution which is practically impossible. So, we can provide weightage to the incidents.
To illustrate:
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents. Weightage for small incidents are 1. Hence 8/(4*1) = 2 is the average cycle time.
Day 2 :
The second days, Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time, a support team takes 8 hours to deliver 4 medium incidents. Weightage for medium sized incidents are 2. Hence 8/(4*2) = 1 is the average cycle time.
This reduction in the cycle time shows the higher productivity. This is a dependable metrics.
Illustration for lead time and priority: "Lead time" is the time it takes for one unit to make its way through operation from taking the order to delivery. This definition assumes that all deliverable are of same priority. However, the software support works on priority. And we ‘park’ the low priority incidents when relatively higher priority come into the queue.
So, to illustrate,
Consider three incidents A, B and C and all are of same size and came to the backlog at same time.
A came to the queue first and was delivered in 3 hours. Lead time for A is 3 hours.
B is of low priority where C comes with high priority. Hence, we park B and take C next to deliver in 3 hours. Now the lead time for C is 6 Hours. Now, B is brought from parking to delivery queue. Which has a waiting time of 6 hours. Now B is delivered in 3 hours. Hence the Lead time for B is 9 Hours.
Now, we should be able to distinguish the time spent in backlog and the time spent in parking. Because the lead time is going to be used in discussing the backlog health.
So, the time spent in parking should be offset, so that we would be able to see the correct scenario. In the example above,
Lead time for A – 3 hours.
Lead time for B is 9 – 3 (parking hours) = 6 hours
Lead time for C is 6 Hours.
Conclusion:
Hence, for both cycle time and Lead time, the time spent in parking should be deducted before calculation.
And for cycle time the incidents should be given weightage before calculating the cycle time.
