WIP Limits in Practice: Part 2

The previous post discussed if you should apply WIP limits per stage of your value stream, per stream, per portfolio, or across portfolios. In this post, we’ll see how to arrive at a numerical value for a workstream.

Please remember that these posts are in the context of improving system performance by regulating usage. Although broadly applicable, the set up described here reflects the situation in large organizations that aren’t as digital-savvy as the best tech companies - places where tech is mainly seen as a functionality-delivery system (feature factory) and where the business drives tech very hard, often at the cost of system performance.

Workstream Specialists

To arrive at limit per workstream, we need to consider its composition. Development workstreams in these organizations develop and test functionality till the “system test” stage before handing it over to a common workstream responsible for integration and operational readiness testing, staging and release into production. This is not ideal but it’s where most large organizations are.

A development workstream in this situation might consist of specialist analysts, developers of different specializations, and QA specialists. Scrum masters, coaches, and engineering managers don’t affect the WIP limit calculation. UX design and solution architects are typically shared upstream. What is the number of in-flight stories that such a workstream can handle without choking?

The Minimum Limit

The bare minimum is simply the total count of the specialists assuming each can work independently on one story at a time. Let’s take an example. A team of 10 people consists of one analyst, one scrum master, three UI developers, three application developers and two QAs. In this case, the total count of specialists that work on stories is nine. Should that be the WIP limit? In most cases, such a low limit would result in near 100% flow-efficiency but at the cost of throughput. Just like a nice wide road with hardly any traffic.

A Viable Limit

We want good flow, but we don’t want to hurt throughput too much. A more reasonable WIP limit would be bound by the minimum of what each specialization can process in a week, at least to a first approximation. For our sample team, what is the number of average-size stories that each specialization can process in a week, after setting aside some time for L3 support, tech debt reduction, meetings, training, improving automation, and other supplementary activities?

It might look like the table below, based on estimates or historical data. This is just an example; actual numbers might vary by situation.

The throughput of this team is bound by the analyst. Going by the thumb rule of the minimum, we arrive at an in-flight WIP limit of 3 stories x 4 stages = 12 stories for this workstream. That’s likely to provide decent flow-efficiency. It might result in some spare capacity for the developers and QAs which could be treated as additional capacity for the supplementary activities mentioned earlier.

We stay with this WIP limit for a while and observe its impact on flow and throughput before deciding to tweak it upwards or downwards.

Test Your Limits

Is it too conservative to go with the least weekly turnover among the specializations? Given that everyone else can do more, could we have at least used a limit of 4 x 4 = 16 if not with 5 x 4 = 20? Well, a limit of sixteen will soon result in work piling up in front of the analyst.

You might say that the team is unbalanced. A team with perfectly balanced capacities would be able to process the same number of stories per week across all stages or specializations. True, but that’s usually unrealistic. Staffing constraints, unplanned unavailability for development work, and other such factors make balance elusive. Nevertheless, you are challenged to ensure adequate flow and throughput.

Quiz

• Since user stories may have different sizes, would it make sense to use a WIP limit based on in-flight story points instead of the number of in-flight stories?
• Why don't we base this on development velocity? If we plan to only take up as much work as the velocity of the last sprint, isn’t that equivalent to limiting WIP?

The next post will describe how to come up with a number for a cross-portfolio limit.

Until then, take care and prosper.

Sriram