WIP, or Work in Progress (AKA Work in Process) is the number of tasks that the team is currently working on.
All the tasks which have been started, but have not been completed yet, increase the WIP. Thus, if the first column on our kanban board is ToDo, and the last one is Production, then WIP includes all the tasks that have left ToDo, but have not been deployed to production yet. It does not matter whether we are actively working on them, or whether they are waiting for the QA team to have sufficient bandwidth to take care of them. This is not important. What matters is that the work has been started, that they are “hanging over our heads”, that they cannot be crossed out and forgotten.
Unclosed loops
Your question could be what the cost of tasks which have not been completed and are still “hanging over us” is. None, in theory, quite big in practice.
These are like the unclosed loops from David Allen’s Getting Things Done method. They do not seem like much, but in an imperceptible way they are taking away some of our bandwidth. We are not doing anything with them, but we are still thinking about them and getting frustrated when, time after time, we realize that this task is still not completed.
In the case of software development, the cost of such unfinished tasks may even be higher because they usually have to do with unfinished code, which lies somewhere in the repository, perhaps making work on the next tasks more difficult.
In the next installment of this series, I will list the potential issues related to high WIP.
P.S You will find much more Kanban goodness in my book — “Kanban for your team” 🙂