WIP Limits That Survive an On-Call Rotation: Kanban for a Support Team Buried in Tickets
Kanban WIP limits for a support team only earn their keep if they survive real on-call chaos, not just a calm planning meeting. A support or platform team doesn’t get to choose when work arrives. Six other teams file requests whenever they hit a problem, an incident pages someone at 2 a.m., and a two-week sprint commitment made on Monday is fiction by Wednesday. Kanban fits this kind of work far better than Scrum does — but the WIP limit you copied from a blog post, some round number like ‘three items per person,’ rarely survives contact with an actual on-call rotation.
What good Kanban WIP limits for a support team actually look like
The official Kanban Guide from Kanban University treats WIP limits as a starting policy to inspect and adapt, not a number to set once and forget — which is exactly where most support teams go wrong.
Why a per-person limit breaks first
A flat ‘three items per person’ limit assumes every item takes roughly the same effort, which is never true on a support team. A one-line config change and a production incident both count as ‘one item’ under that rule, so the limit either blocks the team from picking up a two-minute fix because they’re ‘at WIP,’ or it lets someone quietly sit on three incidents at once because the counter never noticed how heavy each one actually was. Either failure mode trains the team to stop trusting the board within a month.
Set limits by class of service, not by headcount
- Give incidents their own swimlane with no WIP limit at all — or an effectively unlimited one — because artificially blocking an incident to respect a number defeats the entire point of the board.
- Cap standard requests at a limit tied to the column, not the person — for example, no more than six items in ‘In Progress’ regardless of who’s working them, so the whole team feels the pressure to finish before starting.
- Track cycle time by class of service separately. A standard request and an incident should never share the same average-time metric — blending them hides whether either one is actually getting worse.
The escalation is the real test of the limit
Any WIP limit looks reasonable on a quiet week. The test is what happens when the column is already full and a P1 lands anyway — does the team have a pre-agreed rule for what gets pulled off the board to make room, or does the on-call engineer have to improvise a judgment call at 2 a.m. while three other people are asking for updates? Write the swap-out rule down before you need it: usually, the newest low-priority item in progress gets pulled back to the queue, not the one closest to done. Deciding that in the moment, under pressure, is how good WIP limits quietly get abandoned.
None of this requires a big-bang Kanban rollout. Most support teams get more value from spending a week just tracking their real cycle times honestly than from spending that same week debating the perfect WIP number. The number matters less than whether the team actually stops to ask ‘are we over the limit?’ before pulling in new work — that habit is the whole system, and it’s a much smaller lift than any of the multi-team scaling moves it sometimes gets compared to, like splitting a Scrum team into three or absorbing the coordination tax that comes with Scrum@Scale.
Further reading on Kanban WIP limits for a support team
If your interrupt-heavy team is being pushed toward a formal scaling framework instead of just fixing its WIP limits, the SAFe vs. LeSS vs. Scrum@Scale comparison is worth reading before you commit to more process than the problem needs. In most cases, well-set Kanban WIP limits for a support team solve the actual problem without needing a scaling framework at all.