How would you implement Classes of Service in Kanban?

WHAT THIS TESTS: This question probes your practical understanding of Kanban as a risk management framework, not just a task board. It tests your ability to go beyond simple prioritization and apply explicit policies to manage different types of work based on their cost of delay. The interviewer is looking for evidence that you can manage flow, stakeholder expectations, and system-wide impact, not just individual tasks.

A GOOD ANSWER COVERS: A strong answer has four parts. First, define what Classes of Service are: policies that dictate how to pull different types of work through the system, based on their risk profile or cost of delay. Second, describe the common classes: Expedite (for urgent, high-cost-of-delay items), Fixed Date (for items with a hard deadline), Standard (the default), and Intangible (important but not urgent, like tech debt). Third, explain the implementation mechanics: using visual signals like colored cards or dedicated swimlanes, and setting explicit policies for each (e.g., 'An Expedite item bypasses all other queues and is not subject to column WIP limits, but the system-wide WIP limit for Expedite is 1'). Fourth, discuss the trade-offs: expediting one item necessarily delays all others, increasing their cost of delay.

COMMON WRONG ANSWERS: A major red flag is confusing Classes of Service with simple priority levels (e.g., 'P0, P1, P2'). The key distinction is that a Class of Service has a unique pull policy associated with it. Simply labeling something 'Expedite' without changing how it's handled by the system (bypassing queues, ignoring WIP) misses the entire point. Another weak answer is failing to mention the system-wide consequences. Saying 'we just work on the Expedite item first' without acknowledging that this action ages and adds risk to all other work in progress is a junior-level response.

LIKELY FOLLOW-UPS: Be prepared for 'How would you introduce this to a team that's never used it before?' or 'What happens if stakeholders start trying to make everything an Expedite item? How do you handle that?' The answer involves data, showing the impact of expedite items on the lead time of standard work, and having firm, pre-agreed upon policies with product and business stakeholders.

ONE CONCRETE EXAMPLE: Imagine a team has three items ready to be pulled into development. Item A is a production outage causing 10% of users to fail checkout. Item B is a feature promised for a major industry conference in 3 weeks. Item C is a standard, valuable feature with no hard deadline. Item A is an 'Expedite' class: pull it immediately, breaking WIP limits if necessary, because its cost of delay is massive and immediate. Item B is 'Fixed Date': it must be finished by a certain date, so it gets priority over standard work but doesn't bypass all rules like an expedite item. Item C is 'Standard' and will be pulled when capacity is available after the others are handled according to their policies. This shows you can manage different risk profiles simultaneously.