Suggested application: When finished drafts, designs or client deliverables accumulate awaiting approval, treat review as unfinished work rather than an administrative afterthought. Agree a boundary around that work, then decide what the team will do when the boundary is full. The aim of this trial is to examine your review workflow, not to promise faster delivery or impose a universal limit.
Map the review that actually happens
Kanban University describes Kanban as a management method applied to an existing way of working, rather than a replacement process. Its practices include visualizing work and workflow, making policies explicit, and improving collaboratively. This supports starting with your current review arrangements instead of introducing a new approval hierarchy. [1] [3]
Suggested application: Trace a recent deliverable from draft completion to client delivery. Identify who checks it, who can approve it, where revisions happen, and whether client approval is separate from internal review. Represent those steps on a shared board or list. Preserve approval responsibilities; helping prepare a review does not automatically grant someone authority to sign off.
Define exactly what the limit counts
Atlassian defines work-in-progress limits as maximum amounts of work within workflow statuses. Kanban University describes pulling work into an activity when capacity exists within its local limit. These are explanations of the method, not independent evidence that a particular review limit will improve your team's productivity. [2] [3]
Suggested application: Use a combined review boundary covering both awaiting review and active review. Define entry as a deliverable being ready for its named reviewer, with the required brief and supporting material attached. Define exit as recorded approval or an explicit return to revision. Keep blocked reviews inside the boundary. If revisions leave it, keep them visible elsewhere and require capacity before they re-enter.
Choose a provisional limit and write the response policy
Atlassian recommends observing work in each status before choosing limits together. It also advises discussing why limits are reached rather than arbitrarily changing them. Its implementation examples include helping with reviews when another stage cannot accept more work. [2]
Suggested application: Observe the current queue and discuss reviewers' actual availability before choosing a provisional ceiling. Write this policy: When awaiting and active reviews reach our agreed limit, we help clear reviews or resolve blockers before starting more upstream work. The review owner identifies useful assistance, such as checking requirements or obtaining missing material. Completed drafts awaiting entry remain visible; they are not relabeled to evade the limit.
Suggested application: Add an urgent-work exception requiring a named decision-maker, a recorded reason, and explicit acknowledgment of any temporary breach or displaced work. Hypothetical example: A design studio's review queue is full when a client requests an urgent correction. The owner authorizes the exception, records it visibly, and asks another teammate to gather missing assets for a blocked review rather than start another draft.
Run a short trial and inspect the whole workflow
Suggested application: Agree a short trial and a review meeting in advance. Record queue size, elapsed time awaiting review, and completed deliverables consistently. For work still waiting, retain its original entry time. Record blocked reasons and urgent exceptions alongside those observations. Compare the trial with your initial observations without treating a small sample as proof of improvement.
Suggested application: At the review meeting, ask whether the limit prompted useful assistance, whether approval availability matched demand, and whether waiting work accumulated upstream instead. Adjust the ceiling or policy collaboratively. Consider changing review availability or deliverable scope when those are the issues, rather than simply raising the limit.
Avoid cosmetic fixes and use a launch checklist
Our analysis: Counting items is a coarse measure: a small correction and a substantial proposal occupy the same slot under this policy. A limit is not additional reviewer capacity. Treat size differences and unavailable approvers as separate planning questions. Common mistakes to avoid are hiding blocked items, declaring work approved without authorization, and making every deadline an urgent exception.
Suggested application: Before launch, check that the workflow is visible, entry and exit rules are written, a provisional limit is agreed, blocked work still counts, and someone owns exception decisions. Confirm who records waiting time and completions, and schedule the collaborative review. Keep the policy small enough that everyone can explain what to do when the queue is full.
Sources
- The Official Guide to The Kanban Method | Kanban University
- Working with WIP limits for kanban | Atlassian
- Principles and General Practices of the Kanban Method | Kanban University
Prepared with AI assistance from the linked public sources, checked on 2026-10-09. Examples are suggested workflows, not claims of hands-on product testing.