A kanban is used to make claims against the productive capacity of some resource. If I have a kanban, I can give it to you in exchange for an object or process of real value. The value of a kanban depends partly on time. The most relevant temporal data about a kanban are:
…from which we calculate lead time and cycle time. A regular kanban represents a commitment–a real claim against real resources. When a kanban is exchanged, it is with an expectation of certainty that the work order will be satisfied.
Planning decisions, by contrast, involve uncertainty about work that we might perform in the future. Work requests placed at the end of a deep backlog do not represent a commitment to deliver. Pending work requests are always temporally contextual. They can only represent current understanding and intent, and the world will change before they enter production. The longer the backlog is, the greater the uncertainty about relative priorities and lead times.
Such uncertainty is not a problem as long as we are always able to determine a satisfactory answer for what to do next. You can’t utilize more capacity than you have, and adjustments to capacity have a lead time of their own. Your plans and priorities are sufficient as long as you always know what to do next. An efficient planning process is just barely sufficient to provide that information.
The priority filter is an attempt to define a planning process that directly represents the distribution of uncertainty of pending work requests. The work requests themselves are represented as kanban-like tokens. However, a kanban as we’ve described it really only works within the context of carefully controlled queues and processes. A kanban is a commitment, when what we really need is an option. Still, the kanban is a convenient representation for visual control, so what’s stopping us from defining a new kind of option kanban for planning purposes? Nothing!
Like a real kanban, we want to encode information about the scope and value of the request, but the temporal information we need will be different. I will argue that there is only one thing about time that we need to know about our option token: the expiration date.
Placing a token in one of our priority buffers amounts to buying an option to schedule the work for production. The price of the option is set by the capacity of the buffer. The expiration date is calculated from the purchase date and a duration that is also bound to the buffer. So, the priority 3 buffer might have a capacity of 8 and a duration of 30 days. When a new token is placed in the buffer, we calculate the expiration date and the token begins to age. Our priority 3 option gives us the right to bid for any higher-priority options that become available. Availability of a priority 2 option triggers a comparison of priority 3 tokens to select one for promotion. All of the p3 tokens are ageing, and any that are not exercised before their expiration date are cancelled. A cancelled option might return to the deep backlog, or it might disappear entirely. Age then becomes a first-class consideration for competition, where a nearly-expired token may be promoted over a higher-value token that is brand new.
In this way, we work our way up the priority ladder, incrementally investing as our certainty improves, until we finally earn the right to buy a real kanban that we can exchange for the real goods or services offered by our production system. It’s only when we can afford to buy a real kanban that desire becomes demand and the lead time clock begins. If we end up getting cancelled, it will likely be while it is still cheap to do so. We’re only out the cost of our options, which should have been much cheaper than the cost of a real kanban, which we only want to buy if we’re certain that it’s for something that we want.