Where Do WIP Limits Matter Most?

You know what WIP limits are. But what do they apply to?

Is it:

the number of stories a team has in flight?
the number of stories or tasks in a specific stage in the team’s workflow?
how many tasks every member works on “at the same time”?

I think it’s all of the above, but this is a trick question. The list is missing an option that’s often in the blind spot. These WIP limits, if set within certain ranges, will help a team’s work flow better and result in higher quality — but they can only go so far.

The missing option is portfolio WIP: how many features, epics, technical initiatives, projects, and other big work are in flight.

Think about it. If the team has only one feature, team-level WIP limits will help them deliver the feature’s stories gradually. But if they have multiple big items to work on, their respective pieces will all fight for attention in the team’s WIP-limited queue, and all of them will be delayed some (or a lot).

Therefore, WIP limits on the portfolio matter more than on the team’s workflow.

These days, technical teams are more used to limiting WIP, but that’s not so much the case elsewhere in the value stream. Product and business use another concept: prioritization. However, prioritization is not going to help if the project portfolio or roadmap is too crammed.

If your product development or solution delivery doesn’t produce results in a timely manner, manage the project portfolio first and then worry about team WIP.