Friday, January 17, 2014

Kanban WIP Limit - How to?

How Kanban helps with Work In Progress (WIP) limit? Officially speaking Kanban proposes limiting the WIP in all columns but after struggling with some tools "deficiencies" I came to the realization that there are two types of WIP limits: those related to "columns" or "value stream states" and those related to "personal" instant capacity.

Limiting the WIP per person is trivial, a good number is to allow handling no more than 2 standard or intangible tickets in that order plus 1 expedite plus fixed delivery date which will be actually exceeding the limit imposed of 2 per person. The question is how to enforce it. JIRA at least does not have a good way to limit personal WIP limits, would you vote for it please?. The Kanban method tries to address the WIP limit with just limits in the value stream states or columns but I argue that is not enough.

In terms of columns we have queues for example which should be adjusted empirically. On the other side we also want to visualize the personal WIP limits in columns for which our board must be designed carefully. What you might think is a stage to be used across multiple teams should not be modeled as just one column but actually as a number of columns matching the amount of teams involved.

If you have Back End (BE) and Front End (FE) developers and the FE basically pull the work after the BE has finalized their part the pulling system just behaves as expected (pulling from the previous stage).

However if they can work in parallel then you will be tempted to create a common state to describe “dev-in-progress”, and use basically a different swim lane for the two teams. While the separated swim lanes will allow further visualization if you do not create separate columns for them you will be mixing the two concerns on a unique WIP limit (specified in the column) which would be incorrect. The fact that they are columns does not mean that all tickets need to stay time in both of them. This column skipping is not a violation of the Just In Time (JIT) system. The correct workflow should exist to avoid tickets to be pulled from BE into FE but on the contrary to pull them from the backlog.

While you could set WIP limits per team swim lane the WIP limits for queues will still need to be set by columns generating a less appealing board. If you want to visualize several projects in swim lanes you have no option other than using WIP limits in columns. The same applies for swim lanes dedicated to any other kind of criteria like classes of services.

I have found in practice that setting the personal WIP limits alone will be enough for a gradual reduction of WIP. However setting limits in queues is as well very important otherwise your cycle time will increase for no reason, you won't be able to balance the demand versus throughput neither control waste generation resulting from prioritization. A good personal WIP limit is 2 standard item per person with an additional expedite or fixed delivery date item. A good queue WIP limit is 5 per person considering you are trying to fix a ticket per day and that members of the team usually don't get more than one week vacation per individual in a row. Your mileage will vary of course but this should be at least some food for thought.

These complexities are usually not easy to be visualized in just one view so you could visualize the number of issues per member for WIP limits in a classical table layout, the number of issues per team in specific queues in a classical table layout and finally the total number of issues in the kanban board. All this is possible using JIRA Agile for example.

You can read a bit more about this issue in Personal WIP limit directly impacts Cycle Time

3 comments:

Anonymous said...

Thanks for the detailed clarification and thanks for throwing your experience into the game too.

Nestor Urquiza said...

Anytime @MarcO. This feature is definitely something that not only managers but the staff will appreciate, and ultimately the company because it genuinely eliminates task switching costs (task switching is the real issue and not multitasking).

Anonymous said...

Absolutely - the context switching costs as we in our company refer to it is the unknown (IMHO very high) time waste one can have when working in several cross functional teams plus in the end also a "topic / organisational" team. All projects/initiative want their tasks to be solved "in time" for acheiving their individual projects / initiatives goal(s) plus all other tasks like administrational tasks / people development tasks (can be project independent) want to be completed too.

Followers