Manage Work in Process (WIP) by Focusing on Finishing

Work-in-Process (WIP) is not just the amount of work waiting in a queue. It is not even the number of stories or features that have been started yet not completed. WIP is the total of all the MVPs and MBIs that have been started yet not completed. While a story or feature may be complete, it is still a work in process if it hasn’t been released. Managing WIP is not done merely by having WIP limits in queues to manage the waiting time in queues.

Managing WIP is a continual 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. We are not suggesting “one-piece flow” that Lean-Manufacturing emphasizes; rather, we are trying to avoid working on too many things at one time.

Here are some symptoms that 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.

A team working on two things simultaneously when they could be focusing on just one will delay the delivery of both. But what is not so clear is that doing this injects delays into both workflows. These delays in workflow and feedback induce more additional work. This creation of new work is why an interruption delays what people are working on by more than the time of the interruption itself.

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 start 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, which increases both quality and efficiency.

A note on WIP limits

Using WIP limits on queues is one way to manage WIP. But it’s not always the best. WIP can be controlled by having teams pull work only when they have capacity. Doing so sets an overall limit for the team.

Why Amplio Development Uses Work in Process and not Work in Progress

We should always use intention revealing names, phrases, or names of things that describe what they are referring to. There are currently two phrases for WIP. One is “work in progress,” whereas the more accurate is “work in process.” This difference is not academic, as the usage of ‘progress’ can lead to bad practices.

Progress means “forward or onward movement toward a destination.” But WIP refers to work that has started but hasn’t been completed. Work that is not progressing at all is still WIP. The English use of work in progress does not include blocked work. But it is WIP. This often leads teams new to Kanban to not include items that are not progressing (i.e., they are blocked) towards their WIP limits. Doing so, however, is a bad practice.

“In process” means “of, relating to, or being goods in manufacture as distinguished from raw materials or from finished products.” English tells us that something blocked is not in progress but is in process.

It’s worth having our words mean what is inferred by their standard definitions.

It is worth noting that Scrumban (the first book on Kanban) used process, as does Don Reinertsen’s work.

Go to Amplio Development: The Path to Effective Lean-Agile Teams 

Go to Being a Professional Coach