Payments Support: The Expedite Lane and the Utilization Dashboard
Payments Support is an 11-person team responsible for a payment gateway used by 300 merchants. It has run two-week Scrum sprints for a year, but 38% of each sprint turns out to be unplanned work. There are no WIP limits, and each engineer typically has six to nine items in progress. A sales director routes a standing expedite stream through a shared chat channel, averaging five items a week, which the team picks up immediately regardless of what is in flight. Cycle time is three days at the median and 17 days at the 85th percentile. Blocked items wait an average of nine days for the central database team. Daily standup has become a status report to the engineering manager, who has proposed individual WIP limits of three per engineer plus a personal utilization dashboard, because idle people are the real cost. The team wants to adopt Kanban properly but is split on whether to keep the two-week cadence.
1. Should the team move to flow-based Kanban, and what are the first four policies you would put in place? Justify each.
Read the worked answer
Yes, to flow-based work management with a retained cadence. The demand profile is arrival-driven (38% unplanned), and the spread between p50 of 3 days and p85 of 17 days is a queueing signature, not an effort signature. A sprint commitment cannot be defended against that volatility, but a two-week replenishment and review cadence is still useful for prioritisation and feedback. Keep the cadence; change the commitment model and the board.
First four policies.
- Explicit team-level WIP limits per stage, set at roughly current minus one, to expose the queues. Team-level, not individual: per-person limits create handoffs and destroy the point of limiting work.
- Classes of service with written policies. Expedite is capped at one in flight, requires a named sponsor and a stated consequence of delay, and preempts visibly. Five unplanned items a week against a team of eleven is roughly a quarter of capacity already spent by someone outside the team; without a cap the class of service is meaningless.
- Aging and blocked policy. Every blocked item carries a reason, an owner, and an age; a daily review of the oldest items replaces general status reporting. Nine days waiting on the database team is a measurable dependency, not a team performance issue.
- Pull at replenishment. Work is pulled only when a stage is below its limit, and the next item is selected against the queue order. This is the mechanism that actually enforces the other three.
Measure cycle-time scatterplot and throughput, not story points. Story points would keep the focus on estimation effort rather than flow.
2. How do you respond to the manager's proposal of individual WIP limits and a personal utilization dashboard?
Read the worked answer
Reframe: the cost is waiting, not idleness. Use Little's Law on the team's own data: WIP = throughput x cycle time, so with throughput held constant, reducing WIP is the only way to cut cycle time. Each engineer holding six to nine items is not evidence of productivity; it is the direct arithmetic cause of a 17-day p85.
On utilization specifically. Queueing behaviour is non-linear: as utilization climbs past roughly 80-85%, waiting time rises steeply with variability, and this team's variability is high. A 91%-style utilization target removes the slack needed for investigation, pairing, and absorbing expedites, and the resulting queue growth shows up as the tail the merchants experience. Idle capacity is not free, but it is cheaper than 17-day tails on a payment gateway.
On individual limits. They contradict the team-level limit: an engineer capped at three items will hand work off or sit blocked rather than swarm, and the dashboard will reward the wrong behaviour. Individual measurement also invites gaming, since item counts are trivially inflated or deflated.
Offer an experiment instead of an argument. Four weeks of team-level WIP limits, with a pre-commitment to hold throughput. Measure p50 and p85 cycle time, throughput, blocked age and reopen rate before and after, and publish it. If throughput holds and the tail shrinks, the manager's hypothesis is answered with their own data. If it does not, we learn something real. The dashboard can be replaced by a flow panel showing WIP, throughput, and cycle-time percentiles.
3. Design the governance for the expedite stream and the database dependency. What would make each of your proposals fail in practice?
Read the worked answer
Expedite governance. A cap of one in flight, a sponsor named per item, and an explicit statement of what gets displaced. Publish a weekly count of expedites and their originators, and route new requests to the sales director rather than the chat channel so ownership sits outside the team. Review the cap monthly against merchant impact; if genuine emergencies exceed the cap, the answer is a capacity decision by leadership, not a higher cap.
Failure mode: expedite creep, where the cap is quietly raised because nobody wants to say no, and the class of service becomes a synonym for 'urgent'. The displaced-work record is what makes the cost legible; without it the cap decays within weeks.
Database dependency. Treat the central database team as an upstream service. Measure the queue age of our requests inside their process, agree a turnaround expectation for a defined class of standard changes (for example schema additions following a template), and create pre-approved patterns so routine work never enters their triage. Consider embedding a database engineer with Payments Support for a quarter, or granting self-service for a narrow, reversible subset with guardrails.
Failure mode: measuring the database team's individual performance and escalating it as a complaint. That produces defensiveness and creative queue management. The joint review should look at shared lead time and the shape of demand, and the improvement target should be one the database team helps define, since they own half the constraint.