WIP Limits in Practice: Part 1

The last post mentioned that WIP limiting is one way of improving system performance by regulating system usage. Here’s some guidance on applying WIP limits in practice.

WIP limits are meant to be applied proactively. In the posts to come, I’ll share some thoughts on the practical difficulties of applying proactive limits in some situations. Reactive measures might work better in these contexts. ?

Proactive limits may be applied to a single stream of work or across multiple streams (portfolio WIP limits).

Proactive Limits per Stream

Let’s say a stream of work S1 is serviced by a cross-functional team of ten people before it merges into a common stream of integration, operational readiness testing, staging, and release. The common stream in the later stages is not ideal but it’s representative of the set up in many large organizations. ?We may determine in advance that S1 may not have more than twenty in-flight work items at any time. Which work items? Epics, features, stories, tasks, bugs, or a mix of them? It’s best to go with the smallest valuable unit of work, which is usually stories. Bugs don’t count when they are against in-flight stories. When the number of in-flight items reaches the limit, new work intake is paused until the work in progress subsides.

Proactive Limits across Portfolios

Large organizations have multiple portfolios of work, at least one per line of business. Each portfolio might be a portfolio of initiatives, projects, or epics (portfolio items) depending on the unit of funding. That’s the granularity at which we apply portfolio limits. By doing so, we ensure that the start-rate of new portfolio items does not exceed the finish-rate. In other words, we ensure flow. Stop starting new work until you finish enough of the ones in play.

Portfolio Limits vs. Stream Limits

In improving system performance by regulating system usage, portfolio WIP limits matter as much stream limits. If you only have stream limits, you might end up in a situation where, in the previous example, you have twenty stories in flight in stream S1, each belonging to a different project/initiative/epic across portfolios. There goes your speed to market. Besides, that’s what leads to twenty different business stakeholders complaining to you about the slow pace of their pet project - enough to keep you awake all night.

Quiz

1. How about WIP limits per portfolio? When would they make sense?
2. What’s more valuable? Whole stream WIP limits or limits per stage of stream (e.g. analysis, design, dev, PR review…)?

In the next post, I’ll share ways of arriving at numerical values for these limits.

Until then, take care and prosper.

Sriram