Tuning WIP limits under Kanban

My engineering teams recently switched over to Kanban, and we’ve been having great success ever since.  One of the things I never fully understood until today, though, was how you tune your WIP limit.  My team had been using a WIP limit factor of 1.5, meaning that for every developer there were 1.5 stories in progress.

We felt this was a reasonable approach; that keeping a high WIP limit would ensure that there was always something for everyone to do and people wouldn’t end up idle.  We were using three service classes to organize the work – production support, product development, and maintenance class.  Things seemed to be going pretty well, and they largely were, but this approach carried significant risk that we ended up paying for today.

I track cycle time as well as a total completed story points for every release, and I noticed that with today’s release we had a significantly higher cycle time and finished about half as many points as we usually do.  Shocked, I took a look at our work in progress on the board and noted that we were at our standard WIP limit of eight.  What was different this time, though, was that almost every story on the board was large: 13 points or more.

For six developers, we had 66 points in-flight.  Digging deeper, our cycle time on a per-story basis had gone through the roof.  Because the stories were so large, and there were so many of them, we ended up leaving a lot of work on the floor when the release, which occurs on a regular two week cycle, arrived to pick up whatever we had finished by then.

As students of Lean, I’m sure many of you have seen this type of diagram before.  It illustrates that by completing work serially rather than in parallel, you can deliver value to your customers faster.  Well, today really brought this point home and in doing so I learned a lot about WIP limits in Kanban.

Part of the benefit of keeping as low as possible WIP limits is that you allow your developers to swarm around as few large in-flight items as possible, ensuring you:

• Get more eyes on a single feature to ensure quality and shared understanding.
• Reduce cycle time on individual stories (maximize developer participation), both reducing the average amount of time spent on stories and ensuring that as many items are deliverable to customers on a given day as possible.

Because we transitioned from Scrum, our product team was used to seeing a large body of work in progress that had been committed to at an earlier date that would end up getting delivered as a release; to them that’s what a team being successful at delivery looks like.  In an effort to ease the transition into Kanban, and also because I didn’t see the risk, I went along with higher work in progress limits so that things generally looked similarly to what they saw as efficiency.  Now I realize this is a dangerous approach that should be avoided.

Instead of using the classes I mentioned above (production support, product development, and maintenance) we are now organizing the WIP rules around the size of the stories (we’re using fibonacci numbers, and this is roughly what breaks down to large and small for us).

• Large Story – Any story that is 8 points or larger can be worked on with a WIP limit factor of 1/3, rounded down.
• Small Story – Any story that is 5 points or smaller can be worked on with a WIP limit factor of 1/3, rounded up.

Our WIP limit factor is now significantly smaller – instead of 1.5 developers per story, we now have .66.  Any excess capacity on a day-to-day basis is soaked up on testing automation, but under this new approach I expect to see cycle time return to normal levels and a much reduced risk of incomplete work at code freeze.  Additionally, we’re balancing our work around the way we actually do work – we want more smaller stories in progress since typically a single developer can work on them, but at the same time we want to see developers swarming around the larger, more involved stories.

I learned two things here.  First, that Kanban really does either require stories to be a consistent size or, if you do want to use size variants on a single board, that you account for this in your rules.   The second thing I learned is that when you keep artificially high WIP limits, even with good intention, you are not likely doing anyone any favors.

Advertisement