Kanban and the Importance of Work In Progress (WIP) Limits


Attending Kanban Training 

It started on a rainy August morning of 2016 in Mumbai. I was thrilled to be attending the Kanban Design Practitioner workshop and was eager to learn Kanban concepts that originated on the manufacturing floor of an automobile company. The concepts are now being relentlessly applied in Agile practices of Information Technology organizations across the world. I hoped to understand the concepts that made the Kanban approach so universally popular. The masterclass started by introducing what essentially is Kanban and the very important concepts around ‘Flow’ and ‘Visualization’. The concepts were deceptively simple and I was feeling very confident by mid-day about my knowledge of Kanban.

Kanban Board Game

Experiences in a Kanban Board Game

What was to follow would make me revise this perception and appreciate the beauty of Kanban. This alteration was caused by a great Kanban board game that we were to play as part of the workshop.

Kanban Board Game

The entire group was divided into 2 teams of 7 participants each. And we were asked to run an Information Technology project with the intention of maximizing the dollar revenue at the end of the game. The game would encapsulate 10 man days and cover a given number of user story cards to be processed. Each card upon reaching the ‘Production’ system would help our enterprise realize a given dollar value. Hence, the greater number of cards completed the higher the dollar earned value. To our team what seemed to be the simplest way to achieve this goal was to increase the ‘WIP’ limits in each of the lanes.

Increasing WIP does not increase Resource Availability

As per our collective opinion increasing WIP limits of lanes would automatically ensure that more cards enter the workflow and hence reach the completion state. We were up for a rude surprise. By increasing the WIP for each lane we started pulling in more cards than we could process. This was because of a basic glitch in our thinking and decision-making process. Increasing WIP did not translate into an increased resource availability. Soon we had a crowded board full of cards and our team’s energy was dissipated by the confusion for having the high number of permutations caused by the scenario. We were unable to move the cards in a continuous flow and our resources were getting eaten up between the different work items.

Limited WIP – the soul of a Pull-based system

Eventually at the end of the game we realized that the concept of WIP is to ensure that number of work items are limited. A high WIP is self-defeating and not in alignment with the concepts of Kanban. A pull-based system with a high-WIP limit is no different from a push-based system. This is because a high-WIP implies that there is capacity available in the lane (even when there isn’t any). Hence, the surrounding environment can pressurize the team into ‘pulling’ more work by citing the capacity available (a deception created by increasing the WIP without increasing the resources proportionately). The WIP limit has to be as less as possible to the extent that it should pinch. A thumb rule is that the WIP limit should be no more than 1 card per resource for any lane.


At the end of the game, our team collectively understood that keeping a low-WIP is supposed to be hard and requires moral courage. A low-WIP ensures the system becomes predictable and delivers output in a continuous flow. A low-WIP also provides flexibility and options in the system when something breaks down causing a bottleneck. The bottleneck is resolved by multiple resources collaborating and focusing on resolving the items causing a break in flow. The epiphany made us realize the beauty of a pull-based system like Kanban and how a low-WIP is the soul of such a system. That day made me an advocate of the adage that the best WIP is 1. However, there are other common practices recommended as well, based on the kind of Kanban system design and policies that help them ensure that all team members in a Kanban system are utilized optimally and flow is optimized as well.

WIP 1.5

Another common principle several thought-leaders advocate is a WIP limit of 1.5 per person in the team.  This is to ensure that if something gets held up or blocked and the person working on that work-item is unable to successfully resolve the block, they should be able to go pick up something else to work on. Keeping a WIP limit of 1.5 per team member helps in doing this.
However, if your team policies say that a team member cannot take up something new while they are working on a blocked card, then perhaps the WIP limit of 1 would work fine.

WIP 2.0

During the last Lean Kanban India conference, in Sep 2016, the well-known thought-leader said that teams starting with Kanban initially should start with no WIP limits.  Once the system achieved some stability, the WIP limit could be defined as twice the average observed WIP for the board.
I thought this was very practical advice for teams who grapple with this question – how to decide your WIP limits when you’ve very little to go on.


Whichever be your favored method of deciding your WIP limits, the important thing to keep in mind is that you need to have some WIP limits!  You cannot have a situation where there are no WIP limits or very high WIP limits.  WIP limits serve as the channel or constraints between which the wworkflows  Without those constraints, there will be no flow.

If you have any other suggestions, please let me know.

Anshuman Singh
Product Manager, Digité, Inc.

Share the Knowledge

Anshuman Singh

Anshuman Singh

Anshuman brings 9 years of experience in Information Technology products and services in India. Prior to Digité, Anshuman was with Capgemini and Tata Interactive where he was responsible for creating and managing key accounts. Anshuman also plays guitar and is big fan of the works of Oasis.

Simplifying Project Management!

Explore Nimble! Take a FREE 30 Day Trial

Other popular posts on Nimble!

We are on a Mission to

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