The board that is really a mailbox: redesigning a congested delivery system
Northwind Analytics has a 12-person product team on one B2B SaaS product. The board has four columns - Backlog, In Progress (WIP limit 8), Review (limit 5), Done - and 63 cards currently sit in In Progress. Cards range from a two-hour copy fix to a four-week data migration; nothing on a card records size or the date it entered. Three account managers add work straight into In Progress whenever a customer complains, roughly 15 times a month. 'Review' means anything from 'needs a designer' to 'waiting for legal'. Nine cards have been blocked on an external identity vendor for more than three weeks, with no flag and no owner. Average cycle time, measured from first board entry, is 27 working days and has been flat for two quarters despite two new hires. The team calls the board 'just a status tracker' and rejects lowering the WIP limit because 'we already have too much to do'.
1. Diagnose the design defects in this kanban system, and connect each defect to a specific symptom in the situation.
Read the worked answer
Five defects, each traceable to a symptom:
- No intake or upstream design. Three account managers write directly into In Progress, so demand is never sized, ordered or agreed. Symptom: about 15 unscheduled arrivals a month and the team's claim that it already has too much to do - the board is functioning as a mailbox, not a system.
- A limit that is not a limit. A limit of 8 with 63 cards in the column is decoration. Twelve people spread across 63 items is over five concurrent items each; congestion, not capacity, is setting the pace. Little's law makes the trap explicit: at 63 items in flight, lead time only falls if throughput rises or WIP falls, and hiring more people into a congested system mostly raises WIP.
- No sizing or work-item typing. A two-hour fix and a four-week migration share one column and one limit. Size variance becomes cycle-time variance, so no forecast is credible and the limit is consumed unpredictably.
- No exit criteria. 'Review' conflates design availability, legal sign-off and technical checks. Because 'done' is undefined per column, items re-enter and age invisibly; Review behaves as a second, ownerless In Progress.
- No blocker policy. Nine items sit on one vendor for over three weeks with no flag, owner or escalation. Blocked work still consumes WIP, so limited capacity is spent on things that cannot move - which is exactly why new hires did not change the cycle time.
2. Propose the redesign, including the sequence in which you would introduce it so delivery does not stop.
Read the worked answer
Sequence matters more than the final board:
Step 1 - Make the invisible visible (week 1). Add entry date, size (S/M/L by historical cycle time) and work-item type to every card. Record arrivals for two weeks: how many per week, of what type, at what size. You cannot set a limit for demand you have not counted.
Step 2 - Model the real workflow, including upstream (week 2). Walk the work, not the org chart. Add Options and Ready columns in front of In Progress so account-manager requests land somewhere visible instead of bypassing the system. Keep the existing columns during the transition.
Step 3 - Write policies (week 2). One-line exit criteria per column, especially Review ('reviewed by named role, no open comments'), a definition of ready, a class-of-service rule (one expedite slot, approved by the product owner, which displaces standard work visibly), and an explicit blocker rule: flagged on the day, named owner, reviewed daily, escalated after three days.
Step 4 - Ratchet the limit, don't slam it (weeks 3–8). 63 → 40 → 30 → target, announced in advance, with the team choosing the target and the pull rule. Limits only work when the people doing the work own them.
Step 5 - Add cadences. Daily standup on flow and blockers; weekly replenishment that selects from Ready against real capacity; monthly operations review of metrics and policies. Handle the nine vendor-blocked items as an explicit decision: park, escalate or cancel - do not let them silently occupy WIP.
3. Which measures would tell you the redesign worked, and what would you expect to see in the first eight weeks?
Read the worked answer
Measure the system, not individual utilisation:
- WIP by column, daily, against the limit - the leading indicator that the policy is being followed.
- Cycle time distribution: p50 and p85, not the mean. The tail is what breaks promises.
- Throughput per week, by work-item type, so that a shift in mix is not mistaken for a productivity change.
- Blocked time as a share of lead time, and average blocker age.
- Queue age in Ready, because an unbounded Ready column simply relocates the old problem.
- Intake capture: count of requests recorded versus requests worked. If that ratio is not 1:1, the bypass is still open.
Expected shape over eight weeks: WIP falls in steps; p85 cycle time falls before p50 moves much, because the tail is made of blocked and oversized items; throughput may dip for two to three weeks as batching and multi-tasking stop, then recover. Judge the change at week eight, not week two. If throughput has not begun recovering by week six while WIP is under limit, the constraint has moved - look at the vendor dependency and at whether Ready is being replenished fast enough. Publish the numbers where the account managers can see them; that is what makes the intake rule enforceable.