{"id":5657,"date":"2016-09-22T16:39:44","date_gmt":"2016-09-22T19:39:44","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=5657"},"modified":"2016-09-22T17:35:42","modified_gmt":"2016-09-22T20:35:42","slug":"case-study-of-a-wip-limit-implementation-why-when-and-how-to-use-wip-limits","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2016\/09\/case-study-of-a-wip-limit-implementation-why-when-and-how-to-use-wip-limits\/","title":{"rendered":"Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits"},"content":{"rendered":"

When you are learning about Kanban, one of the first things you hear is “always limit WIP, you should”<\/em>, or a less Yoda-ish version of it. But when you decide that you will indeed use WIP limits and google “WIP Limits for dummies”, you won’t discover any walkthroughs or easy-to-implement equations to discover what limit to apply to each column of your kanban board.<\/p>\n

In this post, we’ll talk about how was our experience introducing WIP limits on the Elixir Radar<\/a> project, explaining how we used to handle the project flow before the implementation, what was the a-ha moment that made us apply the limits, how we implemented them, the benefits of doing so and some discussion on the technique.<\/p>\n

We hope that, after reading this, you will understand why it is impossible to have a silver-bullet step-by-step walkthrough on how to implement it and hopefully will gather the necessary knowledge and courage to start limiting the WIP in your project.<\/p>\n

Before WIP Limits<\/h2>\n

Initially, we were handling the process flow by looking daily at the kanban board and defining if a person should get more work, help out with other cards that were blocking someone or just wait until the system’s saturation was diminished. We were especially worried about two specific columns: “UX” and “Dev”; that from day one were clearly the bottlenecks of the process. Therefore, we just managed how full those columns and their queues were and then took actions.<\/p>\n

The a-ha moment<\/h2>\n

At a specific moment in the Elixir Radar<\/a> project, we decided to schedule a refining ceremony due to the lack of stories on the refining column. However, at our daily meeting we saw that we had sufficient buffer for both Dev and UX columns.<\/p>\n

\"Kanban<\/a><\/p>\n

Besides that, we observed our lead time breakdown chart (for more information on lead time breakdown charts, check our blog post: Why we love metrics? Cumulative flow diagrams <\/a>) and saw that the tasks were staying too much time on queues.<\/p>\n

\"Lead<\/a><\/p>\n

Based on those facts, we decided to abort the mission and not have the meeting. To tell you the truth, it was so unnecessary that we only held it one week later. Then, we decided to apply the WIP limit so we could have a faster feedback on the process saturation without the need to keep looking at the board and making mind simulations of the process flow.<\/p>\n

How we implemented it<\/h2>\n

In order to start using WIP limits, we did what everyone does: googled how to do it. However, there were not many explanations on how to calculate and apply the limits. But we did find one post that shed some light on how to start it. Pawel Brodzinsky’s blog post “The Kanban Story: Kanban Board”<\/a> and a comment on a forum on how to specify wip limits in Kanban<\/a> gave us some insights and presented two strategies to start WIP limiting:<\/p>\n