Work In Progress (WIP)

The concept of WIP originated in manufacturing, specifically the Toyota Production System, where it was understood that excess inventory (analogous to WIP in software) ties up capital, hides problems, and increases lead times. In knowledge work, particularly software development, WIP manifests as partially completed code, unfinished designs, unverified tests, or features awaiting deployment. Unlike physical inventory, unfinished software doesn't take up physical space, making its accumulation less obvious but equally detrimental.

The primary purpose of managing WIP is to optimize the flow of value through a system. By limiting the number of items in progress, teams are encouraged to focus on completing existing tasks before pulling new ones into the workflow. This "pull system" approach, a hallmark of Kanban, contrasts with traditional "push systems" where work is started as soon as it's available, often leading to large queues and bottlenecks.

The importance of controlling WIP cannot be overstated. High WIP often leads to:

• Increased Lead Time: More items in progress mean each item spends more time waiting or being context-switched, delaying its completion.
• Reduced Throughput: While counter-intuitive, high WIP can decrease the rate at which work is actually finished and delivered.
• Lower Quality: Multitasking and fragmented focus can lead to more errors and less thorough work.
• Hidden Bottlenecks: With many items in various stages, it becomes harder to identify where work is truly getting stuck.
• Increased Risk: Large batches of unfinished work carry more risk of becoming obsolete or requiring significant rework.
• Demotivation: Teams can feel overwhelmed and less productive when surrounded by a large volume of unfinished tasks.

WIP is closely related to several other key Agile metrics and concepts. It is a critical component of Little's Law, which states that the average Lead Time is equal to the average WIP divided by the average Throughput. Therefore, reducing WIP is a direct way to reduce Lead Time, assuming Throughput remains constant or improves. The Cumulative Flow Diagram (CFD) is a powerful visualization tool that explicitly shows WIP as the vertical distance between the "started" and "finished" lines, allowing teams to visually track and manage it over time.

While most explicitly managed in Kanban, the principles of WIP management are also implicitly present in Scrum. A Scrum team's Sprint Backlog represents the WIP for a given Sprint, and the focus on completing Sprint Backlog items before the Sprint Review inherently limits WIP within that timebox. However, Kanban provides more explicit mechanisms for continuous WIP management outside of fixed iterations.

Workflow Visualization: The first step in implementing WIP limits is to visualize the workflow. This is typically done using a Kanban board, which represents the different stages of work (e.g., "To Do," "Analysis," "Development," "Testing," "Deployment," "Done"). Each column on the board corresponds to a specific workflow state.

Setting WIP Limits: Once the workflow is visualized, WIP limits are applied to one or more columns (or states). For example, a "Development" column might have a WIP limit of 3, meaning no more than three items can be actively in the development stage simultaneously. These limits are often displayed prominently on the board.

The Pull System: WIP limits enforce a "pull system." Instead of pushing new work into the system as soon as it's available, teams "pull" work only when there is capacity. When a team member finishes an item in the "Development" column, and that column's WIP count drops below its limit, they are then free to pull a new item from the "Analysis" column (or the backlog) into "Development." This ensures that work is only started when there's an available slot, preventing bottlenecks from forming upstream.

Focus on Finishing: The immediate effect of WIP limits is to shift the team's focus from starting new tasks to completing existing ones. If the "Testing" column reaches its WIP limit, the developers cannot pull new items into "Testing." Instead, they are incentivized to help resolve the bottleneck in "Testing" – perhaps by assisting with testing, fixing bugs, or refining acceptance criteria – until capacity becomes available. This collaborative problem-solving is a significant benefit of WIP limits.

Identifying Bottlenecks: Columns that frequently hit their WIP limits are clear indicators of bottlenecks in the workflow. By observing where work accumulates, teams can identify systemic issues, resource constraints, or process inefficiencies that are impeding flow. This visibility allows for targeted improvements.

Iterative Adjustment: WIP limits are not static. They should be continuously reviewed and adjusted based on the team's performance, the nature of the work, and the desired flow. Starting with conservative limits and gradually increasing or decreasing them as the team gains experience is a common practice. The goal is to find the "sweet spot" that maximizes throughput and minimizes lead time without overwhelming the team.

While most explicitly associated with Kanban, the principle of limiting WIP is also present in Scrum through the Sprint Backlog. The Sprint Backlog represents the WIP for a given Sprint, and the team's commitment to completing those items within the Sprint timebox implicitly limits the amount of work in progress for that period. However, Kanban's continuous flow model allows for more granular, real-time adjustments to WIP limits across different workflow stages.

Benefits

• Improved Focus and Quality: By limiting the number of active tasks, teams can concentrate on completing one item at a time, reducing context switching and leading to higher quality work with fewer defects.
• Reduced Lead Time: Less WIP means items spend less time waiting in queues, accelerating their journey through the workflow and reducing the time from start to finish.
• Enhanced Predictability: A stable, low-WIP system tends to have more consistent flow, making it easier to forecast delivery times and manage expectations.
• Early Bottleneck Detection: WIP limits quickly highlight where work is accumulating, making it easier to identify and address systemic bottlenecks and inefficiencies.
• Increased Throughput: While counter-intuitive, reducing WIP often leads to an increase in the rate at which completed work is delivered, as the system becomes more efficient.
• Better Collaboration: When a WIP limit is reached, team members are encouraged to swarm on existing work, fostering collaboration and shared ownership to resolve impediments.
• Reduced Risk: Smaller batches of work in progress mean less investment in potentially incorrect or obsolete features, allowing for quicker pivots and reduced rework.

Limitations

• Initial Resistance: Teams accustomed to multitasking may find WIP limits restrictive or counter-intuitive at first, requiring a cultural shift.
• Requires Discipline: For WIP limits to be effective, the team must adhere to them rigorously, which demands discipline and commitment.
• Can Feel Restrictive: If limits are set too low or applied too rigidly without understanding the system, it can create artificial idle time or frustration.
• Not a Silver Bullet: WIP limits are a powerful tool but must be combined with other Lean/Agile practices (e.g., continuous improvement, feedback loops) for optimal results.
• Complexity in Diverse Workflows: In highly complex or interdependent workflows, setting and managing appropriate WIP limits can be challenging.

Common Mistakes

• Setting Limits Too High or Too Low: Limits that are too high negate the benefits, while limits that are too low can starve parts of the system or create artificial idle time.
• Not Enforcing Limits: If WIP limits are treated as suggestions rather than rules, the benefits of the pull system are lost.
• Focusing Only on Individual WIP: While individual focus is good, WIP limits are most effective when applied to the collective flow of the team or system, not just individual tasks.
• Ignoring Bottlenecks: Simply identifying a bottleneck isn't enough; the team must actively work to resolve it, rather than just letting work pile up.
• Not Involving the Team: WIP limits should be a team decision, collaboratively set and adjusted, rather than imposed from above.
• Treating WIP as a Performance Metric: WIP is a control mechanism for flow, not a direct measure of team performance. Misusing it can lead to gaming the system.

Real-world Examples

Consider a software development team using a Kanban board. Their workflow stages are "Ready," "Design," "Develop," "Test," and "Deploy."

• Scenario 1 (No WIP Limits): Developers pull new tasks into "Develop" as soon as they finish their current one, even if "Test" is overloaded. Soon, "Test" has 10 items, "Develop" has 5, and "Design" has 3. Testers are overwhelmed, developers are starting new work that won't be tested for days, and lead time skyrockets.
• Scenario 2 (With WIP Limits): The team sets limits: Design (2), Develop (3), Test (2).
  1. A developer finishes a task, and "Develop" now has 2 items. They pull a new item from "Design."
  2. The "Test" column reaches its limit of 2. A developer finishes their current task, but cannot pull a new item into "Develop" because "Test" is full. Instead, they swarm with the testers to help clear the "Test" queue.
  3. Once a task moves from "Test" to "Deploy," a slot opens up in "Test." A developer can now pull a new item into "Develop," and a tester can pull a new item into "Test."
  This forces collaboration, prevents overwhelming downstream stages, and ensures a smoother, faster flow of work.

Best Practices

• Visualize Your Workflow: Use a Kanban board or similar visual tool to make all stages of work and their current WIP visible.
• Start Small and Iterate: Begin with conservative WIP limits and adjust them incrementally based on observed flow and team feedback.
• Focus on Flow, Not Utilization: Prioritize completing work over keeping everyone 100% busy. Idle time can be a sign of healthy capacity.
• Swarm on Blockers: When a WIP limit is hit, the team should collaborate to resolve the bottleneck or complete the work in that stage before pulling new items.
• Make Limits Explicit: Clearly display WIP limits on your board and ensure everyone understands them.
• Regularly Review and Adjust: Periodically assess the effectiveness of your WIP limits and adapt them as your team, process, or work changes.
• Educate the Team: Ensure all team members understand the "why" behind WIP limits and their benefits for the team and the customer.