Allocating WIP Limits for a Kanban System

Overview

I have seen people focus a lot on what the WIP limit should be for a Value Stream stage of a Kanban system. However, once the WIP limit is known, I haven’t seen much thought going into where to put those WIP limits. Hence, this blog!

 

Consider a simple value stream: ToDo -> Design -> Development -> Testing -> Done. Further, break the activity value stream stages, into “InProgress” and “Done”. Next, you want to put a WIP limit of 6 in Design, Development and Testing stages (as an example). I can do this in several ways:

Kanban Board Design

In the example above, all the 3 value stream stages “seem” to have a WIP limit of 6. However, they will each create very different flow dynamics.

1. The “Development” stage has infinite WIP in this example. This is because the “Development->Done” lane has no WIP limit (or infinite WIP limit). One can keep dumping cards into the “Development->Done” stage but it won’t trigger a reaction from the Design, Development or the Testing teams to come together and resolve the constraint.
In fact, it has broken the flow within the Value Stream. We have 2 Kanban Systems now – one from “TODO” to “Development->Done” lane; another from “Development->Done” to “Completed”. Each of these Kanban Systems would land up with their own Cycle Time and Flow Efficiency. We call such a system as “Aggregated Kanban”.

2. Let us now understand the “Design” and the “Testing” stages. Some people might believe that Design and Testing have the same impact. That isn’t the case. “InProgress” or “Done” is just a state(status). It is analogous to a ticket being open or closed.

If this is understood, then it is clear that “Design” stage really has a WIP of 6 in this system, independent of whether the card is “InProgress” or “Done”.

In contrast, Testing activity, which is really “Testing->InProgress”, has a WIP of 3. So, even if the “Testing->Done” stage has 0 cards, you can have a maximum of 3 cards being Tested at any point of time. That wasn’t the original intent.

Both these ways of allocating WIP limits will not break the one Kanban system that was intended.
Hope this blog helps you in allocating your WIP limits to your needs.

Sudipta Lahiri
SVP- Head of Products, Digité

Share the Knowledge

LinkedIn
Facebook
X
Email
Pinterest
Print
Sudipta Lahiri

Sudipta Lahiri

Sudipta Lahiri - Head of Products and Engineering, Digite - Sudipta (Sudi) has been in the IT industry for nearly 3 decades. He brings together a mix of experience across various IT Services and product companies. At Digité, he heads our Engineering and Product Management functions. He leads the development of SwiftEnterprise and SwiftKanban products. Sudipta is passionate about Lean-Agile transformation. He led Digité’s transformation process and helps various organizations in that capacity. Sudi holds a Master’s degree from Indian Institute of Technology (IIT), Madras. Follow Sudipta on Twitter @sudiptal

Simplifying Project Management!

Explore Nimble! Take a FREE 30 Day Trial

Other popular posts on Nimble!

We are on a Mission to
#HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives

Subscribe To Our Newsletter

Request Demo for Nimble Agile

Nimble Agile Project Management

We are on a Mission to #HumanizeWork

Join 150,000+ Pioneers, Leaders & Mavericks receiving our updates!

Conduct Retrospectives