PMI-ACP Optimize Flow: WIP Limits, Little's Law, Team Interfaces and Flow Metrics

Optimizing flow means arranging a team's work so that items move from start to finish quickly and predictably, with as little waiting as possible, instead of keeping as many items open or as many people busy as possible. Flow is the movement of work items through the stages of a workflow; good flow shows up as short, stable cycle times and steady throughput. The PMI-ACP Examination Content Outline makes it Task 7 of the Delivery domain, with three enablers:

1. Limit work-in-progress at all levels — for each person, each workflow stage, each team and across teams and the portfolio.
2. Shield the team from interruptions (e.g., create team interfaces).
3. Use metrics to analyze and improve flow.

The three fit together. Limiting work in progress (WIP) is the main lever, interruptions are the main way uncontrolled WIP sneaks back in, and flow metrics tell you whether a change actually helped and where the next constraint sits.

Neighbouring tasks cover related ground. How to visualize work on a board and read a cumulative flow diagram or burndown chart belongs to Visualize work in the Product domain; choosing and reporting metrics, and forecasting, to Manage agile metrics; value stream mapping and the seven wastes to Recognize and eliminate waste; and escalating blockers to Manage impediments and risk. This lesson uses those ideas only where they decide a flow question.

Limiting WIP makes work finish sooner because each open item competes with every other open item for the same people, so the more items are in progress, the longer each one waits before it is done. A WIP limit is the maximum number of items allowed in a state (a column, a person, a team) at one time. A limit of 4 on Review means Review may hold at most four items; another can enter only when one moves on.

That single rule turns a board into a pull system: work is pulled into a stage when the stage has capacity, rather than pushed in whenever someone upstream finishes. The principle behind it is often summarized as stop starting, start finishing. When many items are open and few are finishing, the cure is a cap on open work; changes that only describe or relabel the open work leave the cause in place.

Limiting WIP brings several benefits at once:

• Shorter cycle time — fewer items share the team's capacity, so each finishes sooner (see Little's Law below).
• Earlier value — finished items reach customers and produce feedback while unfinished ones produce neither.
• Visible problems — when a stage hits its limit and work cannot move, the blockage is obvious instead of hidden in a growing pile.
• Less context switching — people hold fewer items at a time, so they lose less time refocusing.

When a stage is at its limit

When the next stage is at its limit, the right response is to help finish work there — swarm, pair, review, test — rather than start something new. Starting new work upstream only feeds the queue in front of the full stage; helping downstream frees a slot and keeps work moving.

A full column is a signal, not a nuisance to route around. If it stays full day after day, the team treats it as a problem to understand — for example at the daily standup or retrospective — and tries a fix. The general rule: any response that keeps work flowing in while the limit is reached, whether by bending the limit or by relabelling the queue, throws the signal away. A queue with no limit is still work in progress: it hides the bottleneck and lets cycle time grow while the board looks tidy. Measuring a wait reports the problem; only reducing the work in front of the constraint relieves it.

Little's Law states that, in a stable system, average cycle time = average WIP ÷ average throughput. If a team averages 12 items in progress and finishes 3 items a week, an item takes about 12 ÷ 3 = 4 weeks on average. Dividing the other way (3 ÷ 12 = 0.25) is the common mistake; check the units — items ÷ items per week gives weeks.

The law explains why WIP is the first thing to look at when work slows down. If throughput stays flat at 6 items a week while WIP rises from 9 to 18, cycle time rises from 1.5 to 3 weeks. Adding capacity treats a problem the team does not have; bringing WIP back down restores the old cycle time at no cost.

Know the law's limits:

Limiting WIP at all levels means capping open work wherever waiting happens — per person, per stage, per team, per feature across teams and per initiative across the portfolio — because tight limits at one level cannot fix too much work open at a higher one.

• Portfolio. Teams can finish stories quickly while dozens of initiatives inch forward together and none reaches customers. Only a cap on the number of initiatives in progress concentrates capacity so a few finish; changes made inside the teams, or new ways of reporting progress, leave portfolio WIP untouched.
• Across teams. When a feature needs several teams and each team pulls from many features in its own order, every feature waits on whichever team has not reached its part. Limits inside each team do not align the teams' choices; a limit on features in progress across the teams together does, so all of them work on the same few.
• Team goals. Four two-week goals worked in parallel all finish around week eight. Worked one at a time, the first lands after about two weeks, the second after four. When goals differ in value, sequence them by value (highest first). Dividing the team among the goals is still parallel work.
• People. A person's open items are WIP too (next section).

The rule of thumb: put the limit at the level where the waiting occurs.

Context switching lengthens every item's elapsed time, because each switch costs refocusing time and each item waits while the others are worked on. Someone spread across several projects can estimate each task's effort accurately and still deliver late everywhere: the gap is in the time between the work, not in the work.

A simple example: four tasks of about 1 day each. Done one after another they finish around days 1, 2, 3 and 4, so the first delivers value on day 1. Rotated through in small slices each day, all four finish around day 4 or later, because switching adds time. Parallel progress feels productive, but nothing arrives early and the average time to finish rises.

Two changes reduce switching most directly:

• a personal WIP limit — one or two active items per person;
• fewer contexts — keeping each person on one initiative (or one team) for at least an iteration.

The test for any proposed fix: does it reduce the number of things a person holds at once? Measuring the split, or adding meetings and boundaries per context, does not.

Shielding the team means giving outside requests one predictable route into the team's work, so they are seen and prioritized without breaking everyone's focus. Direct requests to individual developers bypass the backlog, add uncontrolled WIP and quietly erode iteration goals. In PMI's servant-leadership framing, protecting the team from this kind of disruption is part of the scrum master's role: interruptions are impediments to remove. The product owner owns the order of the product backlog, so outside requests go to the product owner and the backlog; the developers then select the work for each sprint.

A team interface is the agreed way others engage the team. Good elements:

• One intake channel, ordered by the product owner, instead of many direct contacts;
• Published guidance on how to ask and realistic expected reply times;
• For teams that also run a live system, a rotating interrupt (support) role — one member at a time handles incoming tickets so the rest stay focused, while the team keeps ownership and urgent tickets still get a timely answer.

Ad hoc and mid-iteration requests

The servant leader redirects ad hoc requests to the product owner rather than absorbing them or flatly refusing them. If a regional sales lead asks a tester to build a demo dataset for tomorrow, the scrum master brings the request to the product owner, who weighs it against the iteration's work and, if it truly matters, discusses a change with the team. The rule: the trade-off must be made visibly, by the person who owns the order of the work.

When the product owner is the source of churn — adding items to the current iteration so often that half-finished work is abandoned — the scrum master coaches towards an explicit policy (entry criteria) for mid-iteration work: genuine emergencies such as a production outage enter now; ideas that can wait go to the product backlog for a later iteration. A useful policy distinguishes between the two; a rule that blocks every change or keeps admitting every change does not, and coaching the product owner comes before escalating.

An expedite lane (expedite class of service) gives genuinely urgent work a defined path with its own small WIP limit — commonly one item — so it can start immediately while the rest of the system stays predictable. Without one, urgent fixes jump the queue, push several columns over their limits and leave other items stalled, making cycle times erratic.

• Expedite items may exceed column WIP limits. A qualifying item starts as soon as it arrives, even if the stage it enters is full; that immediate start is the point of the class of service. The safety control is the lane's own limit: only one item can jump the queue at a time.
• Explicit entry criteria decide what qualifies (for example, a production outage or a regulatory deadline). If a large share of requests arrives flagged as expedite, the lane is being misused: the fix is to agree the criteria with the business owner, not to change the lane's capacity or the team's hours. If everything is urgent, nothing is.

The general rule: urgent work gets a narrow, explicit path; loosening limits for everyone, or doing the work where the board cannot see it, hides WIP instead of limiting it.

There is no correct WIP limit to look up: the team sets its own limits a little below the WIP it already carries, then tunes them with flow data. Starting slightly below current WIP makes the limit bite without stopping work. Limits come from this team's own workflow and data, and a first limit set now and tuned later beats waiting for a perfect number.

Read the data to tune:

Treat each change as an experiment: change limits in small steps and compare cycle time and throughput before and after. Any move that takes work out of the limits' reach abandons the experiment.

Flow metrics tell the team where work is stuck now and whether a change helped. The key ones for this task:

• Cycle time — elapsed time from start to finish of an item.
• Throughput — items finished per period. To judge a WIP-limit experiment, compare cycle time and throughput together: lower limits should shorten cycle time without reducing throughput. Measures of estimated effort or of how busy people are describe effort, not flow.
• Work item age — how long an open item has been in progress. Averages of finished items only reveal a stuck item when it finally finishes; age compared with the team's historical cycle times flags it while it is still open. At standup, look at the oldest items first, and favour finishing aged work that is close to done before starting anything new. Read age together with position: an item's risk depends on how much of the workflow it still has ahead of it, not on its age alone.
• Cycle-time scatterplot and outliers — when most items finish in a narrow band but a long tail takes far longer, look for what the slow items share (a dependency, a type of change, an external hand-off) and improve that cause collaboratively with the people who own it. Fixes that act on every item, or that only adjust expectations, leave the shared cause in place, and escalation comes after collaboration has been tried.
• Flow efficiency — hands-on (active) time ÷ total cycle time. If an item gets 4 days of work in a 32-day cycle, flow efficiency is 12.5% and about 28 days are waiting. Speeding up any working step can save at most a day or so; shortening the waits between steps saves far more. (Mapping where the waits sit is value stream mapping, covered under Recognize and eliminate waste.)

The constraint (bottleneck) is the stage that limits the whole system's throughput, and improving any other stage does not raise output. Flow data reveals it: work keeps queuing in front of it, and stages after it sit idle waiting for work. If about 14 items a fortnight enter and leave Analysis and Build but only 9 leave Acceptance, the queue before Acceptance grows each fortnight and the team's throughput is 9. Identify the constraint from where queues form and work starves, not from staffing levels, configured limits or opinions — a stage finishing more than others is evidence it is not the bottleneck.

Improve the constraint first: subordinate other stages to its pace (a WIP limit upstream) and add capacity at it — people from other stages helping there, automating its manual steps, or adding a specialist to it. Any change made away from the constraint, or one that only gives its queue more room, enlarges or rearranges the queue without raising output.

Utilization vs flow. Keeping everyone near 100% busy lengthens queues: work arriving at any step must wait for someone to free up, and small variations pile into delays. A team at 95% busy with 30-day cycle times and a team at 75% busy with 12-day cycle times may finish the same number of items a week; by Little's Law the first simply holds about two and a half times the WIP. Push the second team to take on more at once and its WIP and cycle time rise with no gain in output. The idle time WIP limits create is not waste to eliminate — it is the capacity to spend on the constraint. Other valid uses of slack are fine, but when the goal is more items delivered, only help at the bottleneck raises that.