In Kanban one of the most important metric is the lead time – either the local lead time between two stations or the lead time for the whole system, measured from the moment a client demand is accepted until the moment of delivery to the customer.
This latter part is not to be mistaken with a potentially shippable product increment or the comletion of development. Delivery in this case is the delivery of something that fulfills the demand of the customer and is actually usable by the customer.
A more drastic point of view, that could be taken is the time from the acceptance of the demand until the actual usage.
Planning with lead times?
From the question I get it seems that up-front planning with a system controlled by Kanban seems rather difficult to the average outsider – after all there seems to be no upfront planning and the systems only is measured “after the fact”.
You need a stable system
But that is only half of the story. Once you have a decent system in place and collect metrics on the different levels of work you can quite accurately predict the mean time it takes for a certain work item from the beginning of a queue to delivery. Of course this only works if the system is sufficiently stable, having a predictable capacity and a reliable flow management.
Regarding the different levels of work: think e.g. ‘Stories and Tasks’ or ‘Features and Tasks’ or ‘Initiatives, Features and Use Cases’ or other models of different levels of abstraction for work items. Klaus Leopold’s work on the Kanban flight levels is a very good resource with regard to this and details the different aspects from portfolio level to implementations tasks even more.
If you have a stable system with know rates of arrival and throughput you can start to put up virtual “current wait time from here” tableaus. Just like in an amusement park.
CC-BY-SA Martin Lewison
How do you plan in an amusement park?
Now – if your tableaus are reliable – planning becomes kind of easy. How do you plan in an amusement-park? You look at the posted waiting time and decide if you really want to wait this long for this ride. If so you join the queue. If not you go somewhere else. You might come back to see if the queue has become shorter. But you can’t join two queues at the same time. At some rides there might be a fast lane for pre-approved tickets, but those are more expensive, slow down the regular queues and are limited in space. You might decide to leave a queue and go somewhere else as long as you have not actually entered the ride, but then you lose your spot.
Like all analogies this analogy is not a perfect match, but this kind of thinking actually helps a lot in planning when working in a flow based system.
till next time