Work in Progress Limits for Service Teams
Set work in progress limits for a service team by identifying the constrained step, defining ready work, and finishing jobs before starting more.
Work in progress limits cap the amount of unfinished work inside a process. For a service team, they help expose overload and reduce the habit of starting every client request immediately. A limit is useful when it changes what the team does as the queue fills.
Count unfinished work consistently
Define the unit: a deliverable, implementation, or another comparable work item. Include items waiting for review or input if they remain inside the process. Hiding blocked work in a separate list can make the active board look healthy while the client still waits.
Put the limit at the constrained step
Map where work accumulates. If one reviewer must approve every deliverable, starting more production may increase waiting without increasing completions. Set an initial limit based on observed throughput and available capacity, then adjust it using actual results. A copied limit from another team is only a guess.
Define what happens when the limit is reached
Finish existing work, resolve a blocker, help the constrained step, or keep new requests in the ready queue. Do not bypass the limit by relabeling an active item as ‘nearly done.’ If urgent work must enter, identify which commitment moves and who approves the tradeoff.
| Queue state | Team action |
|---|---|
| Below limit; inputs ready | Pull the next suitable item |
| At limit | Finish, unblock, or support review |
| Blocked item | Name missing input and escalation owner |
| Urgent exception | Record displaced work and decision |
In an illustrative team, six deliverables are awaiting one reviewer while three more are started. The useful intervention is review capacity and fewer starts, not asking makers to work faster on additional drafts.
Watch throughput and waiting together
Compare completed work, cycle time, aging items, and rework. A limit that is too low can leave usable capacity idle; a limit that is too high may not change the queue. Review the effects without pretending that one number will remain right as work complexity changes.
Frequently asked questions
Should blocked work count toward WIP?
Keep it visible in the total system load. You may track blocked items separately for diagnosis, but they still represent unfinished commitments.
Can individuals have WIP limits?
Yes, especially when context switching is costly. Coordinate them with the team constraint so local limits improve the overall flow rather than shifting the backlog elsewhere.
Put this into practice
Choose one delivery lane, count all unfinished items, and set a trial limit. Document the pull and exception rules, then review completions and waiting after a comparable period.
For the wider operating context, start with Educo’s service business approach. To discuss the constraint in your own business, talk to Educo.
