The QA Queue Outside the Board
Northwind SaaS has a nine-person product team using a board with columns Ready, Development, Code Review, QA and Done. The team set WIP limits of 4 in Development, 3 in Code Review and 2 in QA. After six months, average lead time has risen from nine days to three weeks, throughput is six items per week, and average WIP is 18. The QA column often shows two items, yet eleven items are waiting in a 'QA queue' spreadsheet. Developers keep pulling new cards when Code Review is full because the review limit is described as applying only to reviews actively underway. Sales escalates about three requests per week, which jump straight into Development. The team says it is 'doing Kanban' because the board is visible and limits exist. The delivery manager wants to raise the QA limit to four to clear the queue.
1. Using the numbers, what is the most likely systemic cause of the rising lead time, and which Kanban practices are being misapplied?
Read the worked answer
Average WIP is 18 and throughput is 6 items per week. Little's Law gives average lead time = WIP / throughput = 18 / 6 = 3 weeks, which matches the observed deterioration. The systemic cause is not simply too little QA capacity; it is hidden and uncounted work in the QA queue plus weak pull discipline. The stated limits total 9 (4 + 3 + 2), yet 18 items are in process, so the limits are not controlling the system. QA's limit counts only active testing, not the 11 items waiting, so real QA WIP is at least 13. Code Review's limit is also interpreted narrowly, and developers keep starting work when review is full. That violates two core practices: limit WIP across the whole workflow state, including queues and blocked items, and pull work only when downstream capacity is available. Making policies explicit is also missing, because the loophole is a verbal interpretation. Raising the QA limit would legitimise more WIP and, with throughput unchanged, increase lead time further.
2. Recommend concrete policy changes for QA and Code Review, and explain the expected effect on lead time and flow.
Read the worked answer
First, redefine each WIP limit to cover all work in that state: items actively worked, waiting for review or test, and blocked, unless a separate visible blocked column is used and still counted. For QA, set a total limit of 2-3 including the waiting queue, and put the 11 waiting items on the board rather than in a spreadsheet. For Code Review, set a limit that includes 'awaiting reviewer' and 'in review', and require a developer to stop starting new work when the review limit is reached. Make pull criteria explicit: an item may enter QA only when a QA slot is free; an item may enter Code Review only when a review slot is free. When a limit is reached, swarm on the oldest item, pair, or split work rather than raise the limit. Expect WIP to fall toward the limit total, queues to become visible, and lead time to fall if throughput holds. Throughput may dip temporarily while the team finishes older work. Track aging and the cumulative flow diagram, not just column counts. Do not set limits as targets or use them to pressure individuals.
3. Design an expedite policy for the Sales escalations that preserves flow. Include entry criteria, capacity and board treatment.
Read the worked answer
Create an explicit class-of-service policy with an expedite lane, not an open bypass. Entry criteria should require a named sponsor, documented customer or contractual impact, a requested date, and an explicit trade-off statement describing what normal work will be delayed. Cap expedite work at one item in the system at a time, or two if the team has measured capacity to absorb it; the cap must count against total WIP, not sit outside it. Put the expedite lane on the board with its own WIP limit and a visible policy. At replenishment or daily standup, the team pulls an expedited item only when the lane has capacity; otherwise it waits in a visible expedite queue. Sales sees the queue and the impact. Track expedite lead time, frequency, and effect on standard lead time. If escalations exceed the cap regularly, treat that as a policy problem to review with Sales, not a reason to remove the cap. The policy should also define who can authorise expedite and how the item returns to normal flow after resolution.