{"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 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 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 <\/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 <\/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 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 So yes, there is no silver-bullet-function that would give you the best number. Or is there? Well, we always knew that something like Little’s Law may be able to give us the right number from the beginning, but we didn’t feel we had enough data to calculate the average throughput for each column to use it. Maybe that will be a future blog post :).<\/p>\n Therefore, we used what we had in hands: we chose to follow the first strategy from the two mentioned above. We decided that as we believed it would give us a faster feedback cycle, and we would reach the right limit faster.<\/p>\n To start, we limited only two process bottlenecks, the columns UX and Developing. We applied a limit of 1 to each of them, since we only had one UX specialist and one developer.<\/p>\n <\/a><\/p>\n Some days passed and we saw that we could actually also limit the queues preceding each bottleneck, in order to clearly block the UX when the “Ready to Dev” column got full. We decided to limit both of them in two stories. As the cards were moving to the right of the board, we decided to also limit the other columns (Ready to QA, QA and Ready to Accept).<\/p>\n <\/a><\/p>\n However, something unexpected happened on the second week. The “Ready to UX” column had space for one more story, which would be the trigger to have a Replenishing (ceremony to choose the next stories that will go to the “input” column, already prioritized) and Refining ceremony. Nonetheless, we saw that “Developing” was now the bottleneck of the system, and “UX” was already blocked due to “Ready to Dev” having reached its limit. We then saw that the limit for “Ready to UX” was too high, which was not expected since we followed the floor approach.<\/p>\n <\/a><\/p>\n With that in mind, we reduced the limit to one.<\/p>\n <\/a><\/p>\n Another thing that we changed in our process was the “Refining” column. We saw that we moved a card from “Input” to “Refining” and then to “Ready to UX” too fast, what made the existence of the “Refining” column questionable. Therefore, we decided to remove it, and define that a card would only be moved from “Input” to “Ready to UX” after the refining ceremony.<\/p>\n <\/a><\/p>\n Later, in order to have better control over ceremony scheduling, we decided to also limit the “Input” column in two stories. That means that we would hold both replenishing and refining ceremonies with only two stories to work on, what would make us more agile in case of changes.<\/p>\n <\/a><\/p>\n After some weeks running with WIP limits, we can already see some benefits in our system. The first one is eliminating unnecessary meetings. This was the trigger for limit implementation and it actually worked: the refining ceremony is only held when necessary and now the process itself gives us the hint to when to have it (when the input column is empty). Besides that, we also only refine two stories at a time, which drastically reduces the time of the meeting.<\/p>\n With the “Input” column limit, we can now predict when the next replenishing ceremony will happen. If we divide the “Input” column limit by the average throughput of the system, we have the number of weeks that the system will likely run with no extra stories. Since our team has the availability to have weekly ceremonies, we define the limit as equal to our system throughput (two stories a week).<\/p>\n A major benefit that happened was the reduction of the stories’ waiting time. As we can see on the chart below, it is clear that the time spent on the “Ready to UX” column reduced since we applied the limits. Moreover, when we compared similar stories, we can see that the average flow efficiency actually improved in 6% (flow efficiency is defined as the touch time divided by the lead time). We know that we don’t have enough evidence to statistically prove this improvement, however we can feel it on a day-to-day basis.<\/p>\n <\/a><\/p>\n A last benefit that we observed is specific to the Elixir Radar<\/a> project, but someone may encounter the same situation in their projects. Our UX specialist has more than one project running at a time, which means that she gets different tasks from different projects at the same time. That makes it difficult to prioritize which task to do first. But now, since she is not the bottleneck of the project, when the limit of the columns in which she works is reached, she can work on other projects without feeling guilty.<\/p>\n After that experiment, Plataformatec’s team got together to discuss the technique and get further insights on WIP limits. And we want to share with you some points:<\/p>\n WIP limit is a step towards collaboration promotion, because if people don’t help each other the system can get deadlocked.<\/p>\n<\/li>\n<\/ul>\n What about you? What do you think about WIP limits and its benefits? Did you like our approach? Share your thoughts with us in the comments below!<\/p>\n When you are learning about Kanban, one of the first things you hear is “always limit WIP, you should”, 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 … \u00bb<\/a><\/p>\n","protected":false},"author":47,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[123,210],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/5657"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/47"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=5657"}],"version-history":[{"count":14,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/5657\/revisions"}],"predecessor-version":[{"id":5682,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/5657\/revisions\/5682"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=5657"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=5657"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=5657"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Before WIP Limits<\/h2>\n
The a-ha moment<\/h2>\n
How we implemented it<\/h2>\n
\n
Benefits<\/h2>\n
Further discussion<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n