Work-in-Process (WIP) is not just the work you are working on. It is anything that has been started and not completed. This means once you have started work on a Minimum Business Increment (MBI), epic or feature, it is WIP until it is released.

Managing WIP is a recurring process. Once you have sequenced your work in the proper order, you can allocate your capacity to the items that are truly most important. Do not start projects that adversely affect more important ones merely to “utilize” your people.

Managing WIP is essential. You are not trying to achieve the “one-piece flow” that Lean-Manufacturing emphasizes; rather, you are trying to avoid working on too many things at one time.

Here are some symptoms for WIP that is out of control.

• People have to wait on other people.
• People are being continuously interrupted by other people.
• There are delays in feedback.
• There is a high multi-tasking cost.

It is clear that if a team works on ​two things at the same time when they could be focusing on just one the delivery of both will be delayed. But what is not so clear is what happens to the work because of the nature of interleaving work; that is, working on one project and then another and then coming back to the first. These delays in workflow, feedback and using information obtained induces yet more additional work. This is why a one week interruption delays what people are working on by more than a week. The week spent on the interrupting work causes additional work to be done because the effort interrupted cannot just be picked up again without a cost.

Common root causes for too much WIP

Besides the obvious “starting too many things” these also are common root causes:

• running mini-waterfalls in a sprint
• having stories (at the team) or epics (at the program) that are too big
• when something gets completed, people (at the team) or teams (at the program) opening something new instead of helping others finish their work
• having developers and testers not collaborating
• having development teams and shared services not collaborating
• not using ATDD (I am not referring to automation of the tests, but given-when-then is much better than “as a user …” when you get to buildable stories.

Create a focus on finishing

Some people attempt to manage WIP via WIP limits. It is usually easier and more effective to create a focus on finishing. Completion exists at many levels: tasks, stories, features, and MBIs.

• When done with a task, look to finish another task in the same story.
• When done with a story, look to finish another story within the same feature.
• When done with a feature, look to finish a feature within the same MBI. This focus quickens the rate of feedback, both increasing quality and efficiency.

A note on WIP limits

We don’t recommend using WIP Limits. They are not really needed and complicate things. In the early part of the value stream, WIP can be managed just by having teams pull work only when they are ready. Otherwise, the focus on finishing can manage WIP. Too many Kanban implementations don’t focus enough on collaboration and cross-functional teams. In this case they sometimes overcompensate by having WIP limits in place.