Friday, March 20, 2009

Kanban & Planning and Estimation

And while we’re on the topic of Kanban controversy against Agile practice stalwarts (Kanban & Retrospectives), let’s revisit Kanban & Planning and Estimation ...

I’ve reported in the past how some Kanban teams eliminate estimation altogether and reduce planning to a very simple prioritization scheme to re-fill slots in the input queue. It’s worth discussing whether or not these are prescriptive foundational elements of Kanban or whether they are in fact choices made in specific situations?

First, let’s look at estimation. Kanban teams often eliminate estimation except when they don’t! What Kanban exposed was the fact that not all requirements or requests are equal from a risk perspective. Some requests carry a significant risk from late delivery due to the nature of their cost of delay (or cost of failure) curve, also known as the market payoff function. If for example, failure to deliver a feature on a given date would result in a Federal government fine for breaking the law, then we can describe this as a unit step cost of delay function with a defined tangible cost. Kanban teams treat requests like this differently from other types of requests. In fact Kanban teams typically create several classes of service - 4 or 5 is typical. Classes of Service are delineated (usually) with different colored tickets on the board and through different prioritization policies. It is normal for higher classes of service to require some form of estimation. The significant cost of delay that can be incurred through late delivery has to be mitigated through estimation and the use of the estimate to facilitate prioritization into the input queue in an optimal fashion. Early enough to insure delivery, not too early as to displace something that might be more valuable at an earlier date.

So, Kanban teams eliminate estimation when the risk profile says it is appropriate to do and don’t when it doesn’t.

What about planning?

Well planning is different in Kanban. A release cadence needs to be agreed based on the transaction costs of delivery/deployment. An input cadence needs to be agreed based on the transaction costs of convening the stakeholders and the coordination cost of bringing them together to discuss the input queue. A standard class of service level agreement with a cycle (or lead time) needs to be agreed as a target for delivery. As for planning in terms of selection of items in the backlog, this is done as late as possible on as little of the backlog as possible. It’s a very Lean approach to planning.

It’s not that there is no planning in Kanban but it is a different approach to planning than either traditional project management or more modern Agile methods such as Scrum.

Related Posts: Kanban & Retrospectives, Kanban in Action. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management