How would you implement Classes of Service in Kanban?

WHAT THIS TESTS: The interviewer wants to know if you understand Kanban as a service delivery method rather than just a task board. Specifically, they are looking for your ability to manage risk and stakeholder expectations by segmenting work into Classes of Service. This reflects the Kanban focus on improving services from your customers perspective and visualizing knowledge work as it moves through a workflow. They care whether you can define explicit policies, protect flow, and avoid overburdening the system when urgent items appear.

A GOOD ANSWER COVERS: First, define each class by its risk profile and customer impact. For example, Expedite might be reserved for critical production incidents that threaten service delivery, Standard for normal feature work, and Fixed Date for work with a known deadline where missing it carries penalty. Second, visualize the class on the board using color coding, swim lanes, or token shapes so the policy is visible to everyone. Third, allocate capacity rather than just priority. This means setting WIP limits per class or using capacity reservation rules so that Expedite items do not completely starve Standard work and cause systemic delay. Fourth, establish explicit policies for how items enter each class and how they move through the workflow, including any pull criteria or service level expectations. Fifth, review these policies with stakeholders so they understand trade offs and why an item cannot simply be labeled Expedite to jump the queue.

COMMON WRONG ANSWERS: A major red flag is treating Classes of Service as just another name for priority labels without changing WIP limits or capacity allocation. Another mistake is allowing unlimited Expedite items, which destroys predictability and overburdens the team. Some candidates also fail to mention explicit policies, suggesting they view Kanban as a visual task list rather than a method for managing risk. Finally, confusing Classes of Service with person based assignment or saying you would create a separate team for each class shows a misunderstanding of workflow.

LIKELY FOLLOW-UPS: The interviewer may ask how you prevent Expedite work from starving Standard work. They might also ask how you would measure the impact of introducing Classes of Service, such as tracking cycle time per class or service expectation conformance. Another common follow up is how you would handle a stakeholder who wants every item to be Expedite.

ONE CONCRETE EXAMPLE: Imagine an e commerce platform where a payment gateway outage requires immediate fixes while the team is working on a new checkout feature. You would classify the outage as Expedite, visualize it with a red card in a dedicated swim lane, and apply a policy that only one Expedite item may be in flight at a time and that the team can pull it immediately. The checkout feature remains in the Standard class with its existing WIP limit protected. You communicate to the product owner that the checkout feature will likely delay by one day, managing expectations transparently while the system absorbs the urgent work without total chaos.