On Setting Your Initial WIP Limits
During a recent training course, I was asked how their team should calculate the initial WIP limits for a team starting out with Kanban. Now, the correct answer is that you need to experiment; find the WIP limit that is low enough to identify bottlenecks & promote a smooth flow, but is still high enough not to artificially create bottlenecks. This answer is all well & good to refine the limits, but doesn't help you when starting.
I want to share my approach, which is based on 4 factors.
- Your Value Stream Map (VSM)
- Your team size
- Your Value Add (VA) time
- The process efficiency
Start by defining your VSM (http://en.wikipedia.org/wiki/Value_stream_mapping). Don't skimp on this, make sure you do it properly. The states in your VSM give you the initial columns on your Kanban.
Let's look at 3 examples: Develop Feature, Hiring Staff and Helpdesk Request. Please note that these are highly simplistic and do not represent any sort of reality :-)
Next define your value added (VA) time and non-value added (NVA) time. Your VA time is defined as the average time spent actively working on a task in the process. Therefore NVA is the average time spent between each process step. For the Kanban you can merge any steps with 0 VA and 0 NVA with the subsequent or preceding step.
Finally, we calculate our process efficiency by dividing our VA with our total time (that is VA+NVA)
Efficiency = VA / (VA+NVA)
"But how to we turn this into WIP limits?"
I'm glad you asked.
We'll start by assuming that your team only works on one process. If there are multiple VSM's for the team, you will need to adjust accordingly by the % of time spend per VSM.
Start with your efficiency. An efficiency of 50% means that your team can do 2 things simultaneously. An efficiency of 90% means that you have very little time between each step, so you can really only do 1 task at a time. And an efficiency of 10% means that your team can do 10 simultaneous tasks.
Divide your team size by your efficiency to get the total number of tasks your team can perform simultaneously. This total will be our total WIP for the entire board. Of course our goal is to improve efficiency, but we are looking for our current WIP, based on the current process.
Develop Feature:
Team size=7
Efficiency=55%
Total WIP = 7/55% ~ 13 tasks
Hiring Staff:
Team size=2
Efficiency=27%
Total WIP = 2/27% ~ 7 tasks
Helpdesk Requests:
Team size=3
Efficiency=65%
Total WIP = 3/65% ~ 5 tasks
Next we proportion out our total WIP by state. So and we spend 40% of our VA time in "Do", then 40% of our total WIP goes to "Do", and so on. Round these off & make sure that all 0's are at least 1 and you have your initial WIP limits.
Develop Feature (13):
Design: 13 * 15% = 1.95 ~ 2
Develop: 13 * 55% = 7.15 ~ 7
Test: 13 * 28% = 3.6 ~ 3
Deploy: 13 * 2% = 0.25 ~ 1
So we estimate that the team of 7 for Develop Features can simultaneously work on 13 tasks based on their process efficiency. The area I would look out for here is Test; this may end up being a bottleneck because the Deploy step is, comparatively, so much faster.
Hiring Staff (7):
Write PD/Advertise Position: 7 * 25% = 1.75 ~ 2
Interview Candidates: 7 * 50% = 3.5 ~ 3
Select Candidates: 7 * 25% = 1.75 ~ 2
Hiring Staff is a lot more straight forward; given the team of 2 and the low process efficiency, the recruiters in this team can hire for 7 positions simultaneously. As long as our initial assessment of VA and NVA was correct, this shouldn't form any consistent bottlenecks.
Helpdesk Requests (5):
Triage: 5 * 4% = 0.2 ~ 1
Assign: 5 * 2% = 0.1 ~ 1
Resolve: 5 * 90% = 4.5 ~ 2
Close: 5 * 4% = 0.2 ~ 1
Finally, Helpdesk Requests is a problem. Because each column needs a WIP of at least 1, resolve is going to be a significant bottleneck. In this case, common sense would suggest to either increase to total WIP so resolve could be brought to 4 or even 9. Alternatively, merge some of the smaller processes such as triage and assign and give the combined status a WIP of 1.