Let's say you have 12 developers working under your direction who will work in 3 different projects. Due its complexity, each project will require 5, 4 and 3 developers each.
What's the best practice to calculate WIP here, is it based on the number of people per sub-team/project? We would like to have a single wall of work to visualize all the three projects progress.
It's better to have each project with its own board, otherwise things can become confusing, or you might miss some things as one team thinks another team "has that one".
Also, it will be hard to manage the WIP limits because it's a sum of WIP limits in fact, and the sum can hide some problems with the individual WIP limits that compose it. For example, one team might be at their WIP limit but the others not, and overall you think you can take some more work for everyone, which isn't the case for the first team. So one board with its own WIP limits per project.
As for what WIP limit value to choose, I would start with 1, 2 or 3, then, after a while, use what you learned from doing the work to see if you need to change them.
Normally a human can only work and focus on one thing at a time, so WIP should be 1. But since some tasks might await some information or discussions in a meeting that needs to be organized later, or be blocked for a short while for some reason, you can use a WIP of 2 or 3 just so that there is some room to handle other things instead of staring at the walls because your WIP is 1 and you can't take any more work, or have to unnecessarily more cards around every time you need to wait a few minutes for some information.
WIP limits are needed to balance 2+ steps of the workflow. So that the constraining step (the bottleneck) doesn't get overloaded. So if you know the team and have a rough idea of who's going to be the Constraint - set the limit to the number of people in that group + some buffer (buffer size depends on the typical duration of tasks). That's provided that the Constraining group of people will each work on a separate task.
The problem with WIP constraints in Software Development - you can't set them if your tasks aren't of standardized size. If 1 task takes a day and the other task takes a week, then all these WIP limits become useless. And this is a common theme in our field.
A simpler and more robust solution is to balance the team so that the 1st step is the constraint. Then WIP limits won't be needed at all:
PS: but I agree with Bogdan - if projects are developed by different groups of people, then you can't set a common WIP limit. One of the projects can easily reach global limits and then all other projects will completely halt.
If it's a shared pool of people who simply switch from one project to another - then you're fine, it looks more like a team working on different tasks.
Very interesting - and somewhat more common than you might expect - situation!
Some questions first -
Are they all just developers - or do you have other roles such as designers, testers, etc.? That affects the design of the workflow. If each person can do all the work on a story or task themselves, then you can have a simple workflow such as Backlog - Committed/ Ready - Doing - Done, but if there are specialized skills, then you would probably want a more elaborate workflow - Design - Test Case - Dev - Automation - validate, etc.
Can they work interchangeably on any of the projects or even tasks within a project? If they can work interchangeably, you can focus on ensuring that whatever tasks are picked up are finished first, before taking up new tasks (Kanban is, after all, about "Stop Starting! Start Finishing!").
The answers to both of the above points impact how you plan your WIP Limits.
For the purposes of visualizing the status of each project clearly, as well as the allocation of developers to each project, it would make sense to have individual swim lanes for each project. However, depending on how much cross-project task allocation you might realistically have, where managing overall WIP becomes most important, you might have a single lane board where all your work gets done. (You could consider different colored stickies for each project if necessary).
Having said all that, the way I would define your WIP Limits would be -
When implementing these WIP Limits, you, of course, consider the overall capacity of each team. So a 3-member team could have a WIP Limit of 4-6, a 6 person team would have 8-12 cards, and so on.
Depending on the answers to the initial questions, you could consider using a Lane OR Column level WIP Limits, as well as individual-level WIP Limits to manage the overall loading of your developers.
If you are using a physical board, besides marking WIP Limits on top of each column or the overall lane, you could use tokens for each developer to limit the number of cards they may have at any time.
If you consider an electronic Kanban tool, consider using a tool that supports all 3 types of WIP Limits.
If you need additional guidance on the Kanban Method, you could check out this article. Separately, we also have this guide on how to design Kanban boards that you might find useful.
Hope this helps.
Disclaimer: I am a co-founder at Digité, where we build Lean/ Agile tools for software and business teams. We have worked closely with the Kanban community in designing our Kanban tool. I personally am a Kanban coach/ trainer and have worked with numerous organizations in helping them implement Kanban.
