WIP limits

Contents 1 Overview 2 Importance 3 PMI-ACP Exam Outline Reference 4 Body 5 History 6 Current practice 7 See also 8 Sources & Reference 9 External Links

Community Guide of the PMI-ACP > Value Driven Delivery

Please contribute to the community. Add content here

Overview

Work in Progress (WIP) refers to the amount of work started at a given point of time. Placing limits on WIP reduces multi-tasking, improves throughput and teamwork.

Importance

Teams adhering to a WIP limit will benefit in ways such as:
- reducing multi-tasking, thus eliminating the waste associated with such a poor practice. As you increase the number of tasks a person is juggling you decrease their capacity
- increasing their throughput, by focusing on only one task at a time you eliminate the waste associated with context switching. In reducing this waste you increase the throughput of the team's results
- WIP limits are placed on teams, which will result in teams swarming issues to preserve their throughput rates

PMI-ACP Exam Outline Reference

Tools & Techniques - Planning, Monitoring and Adapting (page 4)

Body

You are driving down a highway during your daily commute on a nice sunny morning. The highway is busy with lots of traffic but it is moving at the speed limit. Part way along your drive you come to a slow down where traffic is stop and go. After enduring this traffic for a period of time the traffic jam suddenly just ends. No accident, breakdown, or construction is in sight. For whatever reason the traffic is suddenly moving again. Most of us have likely experienced this but have you wondered why it happens?

Whenever an event occurs on the roads most drivers react by slowing down. For example, if a driver touches their brake pedal the driver behind start processing their reaction. If you're too close to the car in front the reaction is often to slow down (even if just a little). The next driver will be impacted by the second driver and so-on down the line. The result is a phantom traffic jam. The more vehicles you have on the road, the more pronounced this affect is. If it's rush hour in a big city such as Toronto, New York or Los Angeles a simple tap on the brake pedal can cause traffic jams lasting hours.

The flow of work is similar to the flow of traffic. In situations where a team has too much work in progress, the end result is often task switching and thrashing. Managers who push more work into the pipeline with the intent of utilizing their resources more fully, actually slow their teams down.

__How to establish an effective WIP limit__

The answer to this question is very situational, and largely depends on your team and the nature of their work. Establishing a WIP limit is not a one time activity. You need to first establish an initial WIP limit, and then through observation and metrics continue to optimize the system by adjusting the limit.

Approaches to help you establish and maintain an effective WIP limit include:

Guess! - despite all of the so called science you could use to establish initial WIP limits, initially a guess is as good as anything. Basing this guess on historical data, or rules of thumb is a good idea but don't spend too much time trying to get it perfect (because you won't). Examining throughput and cycle time metrics, along with cumulative flow charts will help you with this optimization.

Limit task switching - as human's we are not wired nor capable of multitasking. Any time you switch from one work item to another, your brain must put aside the thought process in progress, clear the memory, load the new work item and orient itself. Although in most cases this takes micro seconds in larger complex tasks it can take a long time. So limit the opportunity for people to switch between tasks. Assigning a WIP limit of 2 per person is acceptable as long as you instill the culture of not trying to do both. If they become stuck on the first item and cannot proceed then is the only acceptable time to switch to task 2.

Historical data - over time you will build historical data for your team/organization. As a starting point it would be valid to use this historical data to establish the initial WIP limit. Be sure to account for team composition, and the nature of work when you do this. Do not simply use historical values without this type of consideration.

Inflict pain - when in doubt make the WIP limits smaller. This will inflict pain on the system and bring the impediments and bottlenecks to the surface faster. Finding the impediments and bottlenecks is key to improving your system so do what you can to surface things faster.

Emperical data - through observations and experimentation you will start to establish increasingly realistic WIP limits. As you adjust your WIP limits be careful to monitor the system and learn how the change impacts the throughput and cycle time. Remember it is better to keep your experiments smaller and isolated rather than making large wholesale changes.

WIP limits in methodologies

Kanban - Although Kanban is not a methodology it is being included as an effective tool for to manage WIP. Teams using Kanban effectively will adhere to the WIP limits, and only pull in the next work item when there is sufficient capacity. This simple visual tool helps people focus, while having the impact of improving cycle time and throughput.

Scrum - During the Sprint planning a team works together to accept stories and commit to delivering them during the sprint. The team must never accept more than they can support through the use of story points, velocity and their judgement believes they can accomplish. Then as the sprint proceeds, the team uses a task board to pickup stories to be worked on. Individuals within the team must never pickup more than one item at a time. These simple approaches to managing work discourage the practice of having too much work in progress at any time.

XP - Similar to Scrum, in XP the team only picks up stories one at a time from their backlog. With each occurance the team then finds someone to pair with. Only once the story is complete does the person pick up another story.

Waterfall - waterfall methodologies place the focus on schedule rather than the amount of work in progress. Work is conducted in large batches and once the batch is ready it is passed to the next person down the line. This would be the same as bringing cars onto a highway and batching them before allowing them to move down the road. Imagine the traffic jam this would cause if we batched cars in groups of 100 and released them all at the same time. The same concept applies in Waterfall, and with each handoff the impact is the person downstream will be thrashing as they manage each batch.

__Patterns of good WIP practices__

Continual monitoring & adjusting -

Smaller WIP limits are the norm -

WIP limits inflict pain on the organization in the interest of improving -

Teams are focused on finishing what is started -

__Anti-Patterns of good WIP practices__

Focus on maximum utilization of people -

"It's only one more small thing" -

Response to being behind schedule is to increase WIP -

Not accounting for 'all' work -

History

Current practice

See also

Sources & Reference

- Kanban, Successful Evolutionary Change for your technology business - David Anderson
- Lean-Agile Software Development - Alan Shalloway, Guy Beaver, James R. Trott
- Lean Thinking - James Womack & Daniel Jones
- The Remedy, Lean thinking - Pascal Dennis
- Agile Project Management with Scrum - Ken Schwaber (for SCRUM Perspective)
- The Art of Agile Development - James Shore (for XP Perspective)

External Links