Work-in-process (WIP) is not simply the work items you are working on; it is anything that has been started but not yet completed. This means once you have started work on a Minimum Business Increment (MBI) or epic or feature, it is WIP until it is released.
In knowledge work, managing WIP aims to minimize the number of things being worked on at the same time. It also aims to allocate capacity to the items that are highest value. It is more important to work on important, high value work items than simply to keep people busy, fully utilized.
Here are symptoms of WIP that is out of control.
- People waiting on other people
- People being interrupted by other people
- Delays in feedback
- Significant amount of multi-tasking
All of these represent delays. Delays caused by waiting, delays caused by stopping and starting. Stopping and starting is especially bad because of the additional time required simply to stop one thing and start up the next. That is induced work, waste we bring on ourselves.
Root Causes for Too Much WIP
Here are some examples of root causes for too much WIP:
- Starting too many things at the same time
- Running mini-waterfalls within a sprint
- 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), starting something new instead of helping others finish their work
- Developers and testers not collaborating
- Development teams and shared services not collaborating
- Not using acceptance test-driven development (ATDD)
Focus on Finishing
One approach to managing WIP is to use WIP limits. We do not recommend this: They are not really needed and can often complicate your work.
Instead, it is often easier and more effective to adopt a policy of focusing on finishing. In addition to controlling WIP, you get faster feedback which increases quality and efficiency. A focus on finishing works at many levels.
- When done with a task, try to finish another task in the same story.
- When done with a story, try to finish another story within the same feature.
- When done with a feature, try to finish a feature within the same MBI.
Note: Too many kanban implementations do not focus enough on collaboration and cross-functional teams. Instead, they overcompensate by having WIP limits in place. Effective collaboration reduces the need for WIP limits.
Why Disciplined Agile Uses Work in Process and not Work in Progress
As much as possible, try to use intention revealing names - names and labels that clearly describe what they are referring to. In the literature, you will see two labels for WIP: work in progress and work in process. Work in process is the better term.
Progress means “forward or onward movement toward a destination.” But WIP refers to work that has started but hasn’t been completed. This includes work that may be blocked, not progressing at all. Technically, work in progress would not include that blocked work. And that has led many people new to kanban not to include blocked work in their WIP limits. That is not effective.
By contrast, “in process” means “of, relating to, or being goods in manufacture as distinguished from raw materials or from finished products.” Clearly, that includes work that is blocked.
Related Resources
- DA Value Stream Consultant Resources
- DA FLEX
- DA FLEX Solutions
- Controlling Work-in-Process (WIP)
- How to Ruin a Software Development Organization by Focusing on Throughput
- Focus on Finishing Stories in the Sprint and on Finishing MBIs in the Business Increment
- Running Effective Planning Events
- Flowing Within a Time-box
- Managing Large and Small MBIs
- Why Delays Cause Waste (Video)
- Don't limit Work-in-Progress by Pawel Brodzinski. States the problem really nicely.