I recently suggested that a reasonable lower bound for a WIP limit might be 1.5 per team member.
But then an astute reader called me out on this.
This 1.5 number has a very obvious assumption, that is often simply not true. I mistakenly made the assumption that every team member is working independently.
That’s often not true, and in fact, if often simply should not be true!
There are many times when you may want a WIP limit of less than 1 per team member. Here are some off-the-top examples:
- During onboarding New joiners may actually contribute a negative capacity to the team. That is to say: A team with a WIP limit of 5 may need to go to 4 (or even lower) while training a new joiner, if one or more of the productive members needs to divert their attention to onboarding.
- Pair programming If your team does pair or mob/ensemble programming programming, you may have a capacity limit of 1 per 2 or even 3 or more developers. (Albeit, with the potential upside that each task is completed faster.)
- Any other collaborative work Any time you have frontend and backend devs working together on the same story, or QA engineers working with devs, or the whole team in a conference room brainstorming a new feature, you will have a per-person capacity of < 1 for the duration of that activity.
Of course, as I said in the previous post, we don’t want to adjust our WIP limits too frequently. Once every sprint, or every few weeks is probably sufficient. The goal is to find a WIP limit that averages out to effective for your team.
For example, if you do pair programming half of the time (individual capcity = 0.5), and individual work the rest of the time (individual capacity = 1), then maybe average out the two values for an average individual capacity of 0.75. With 5 team members, that would mean a team WIP limit of 3.75. Round down to 3 or up to 4, then iterate to find what works for you.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)