Limiting Work in Progress (WIP)

For me, it’s all about getting the backlogs together and putting strict limits on WIP. It is a mess to find a bottleneck, or get to done, when too many things are in flight. Remember: there is one expedite slot to override WIP, but only one.

Two ways to limit WIP:

  1. With the value stream mapped, look at the resources within a certain step and ensure there are no more slots than people in that step.
  2. If there is an inability to get the value stream map, or while you’re going there, write a sticky for the name of each developer
    1. With all the things in flight, have a person put their sticky name on the WIP
    2. Have them move their name to whatever they are working on
    3. Don’t allow more things to be allowed in to WIP until there is no way they can put their name on something
    4. Only allow for one WIP per person
    5. Cut the WIP slots in 1/2 for pairing

If you’re trying to enforce pair-programming, or otherwise get cross-functional and more collaborative teams, limit WIP to half the number of developers. There should be a minimum of 2 slots for any one step in the process.

In throttling down in this way, and trying to get a handle on what’s in flight, make this request:

Put your name on what you’re working on
Nothing to work on? Ask if you can help someone else.
Don’t have the right skills for that? Find the bottleneck and work to release it.
Don’t have the right skills for that? Pull in work from the fixed queue.
Don’t have the right skills for starting anything in the queue? Ask the PO if there is anything lower priority to work on.
They don’t have anything? Go find other interesting work.

This entry was posted in #agile explained and tagged , . Bookmark the permalink.

Comments are closed.