How would you implement Classes of Service in Kanban?

What's really being asked

This question assesses your ability to move beyond basic Kanban and apply sophisticated risk management techniques. The interviewer wants to see if you understand that not all work has the same risk profile or cost of delay. They are testing your knowledge of how to create explicit policies to handle different types of work, ensuring the most critical items are delivered appropriately without destroying the predictability of the overall system. It's a test of managing flow and risk, not just a task list.

The full answer

A strong answer will explain the implementation in three parts. First, define the common classes of service based on their cost of delay profile. The four standard classes are Expedite (for urgent, high-cost-of-delay items like a production outage), Fixed Date (for items with a specific deadline and high cost of delay near that date), Standard (for regular, everyday work), and Intangible (for work that has value but no immediate high cost of delay, like tech debt). Second, explain that each class has a different pull policy. This is the key. For example, Expedite items might bypass some columns or even the WIP limit for their column, swarming the team. Fixed Date items are pulled based on their deadline. Standard items follow the normal pull rules. Intangible items are only pulled when capacity is available. Third, provide a concrete example tying a class to a business risk.

The mistakes people make

A major red flag is treating classes of service as just another way to say "priority". For example, saying "Expedite is P0, Standard is P1". This misses the entire point. The difference is not the label, but the behavioral policy associated with the label. A weak answer won't explain how the team's behavior or the system's rules (like WIP limits or pull criteria) change for an Expedite item versus a Standard one. Another red flag is creating too many classes of service (e.g., 8 or 10), which complicates the system unnecessarily and makes policies hard to follow.

What usually comes next

Be prepared for "How do you decide the capacity allocation for each class of service? For example, how many Expedite items can you handle at once?" (Answer: Through explicit policy, e.g., "Only one Expedite item on the board at a time"). Another follow-up could be "What happens to the predictability of your Standard items when you take on an Expedite item?" (Answer: It gets worse. The cycle time for Standard items will likely increase, and their variance will grow. This is a trade-off we make explicit to stakeholders).

A concrete example

Imagine we are preparing for a major industry conference in 3 months. The marketing team needs a specific new feature to be live for the keynote demo. This work item would be classified as 'Fixed Date'. Its cost of delay is low right now, but will skyrocket as we approach the conference date. We would not start it immediately, but we would schedule its start date by working backward from the deadline, ensuring it enters the workflow with enough lead time to be completed. This manages the risk of missing a critical, public-facing deadline. If we just made it a 'Standard' item, it might get stuck behind other work. If we made it 'Expedite', we would be starting it too early and disrupting other valuable work unnecessarily.