We're running a Kanban system but are constantly struggling with how to prioritize and manage different types of work that hit our team—for example, long-term features, immediate bug fixes, and critical compliance updates. I've heard of Kanban Classes of Service. What are the standard classes, and how do we set different policies for each of them to manage our diverse work in progress (WIP) without constantly violating our WIP limits or negatively impacting the overall Cycle Time for regular software development tasks?
3 answers
Kanban Classes of Service (CoS) are explicit policies that define how different types of work should be handled and prioritized to manage risk and deliver on customer expectations. There are typically four standard classes: Expedite (immediate, critical work, lowest Cycle Time), Fixed Date (work that must be done by a specific deadline), Standard (normal work, first-in, first-out), and Intangible (long-term, speculative work with a higher tolerance for delay). To use them effectively, you must define a pull policy for each: for example, an Expedite item jumps the queue and temporarily suspends a Standard item, whereas a Fixed Date item might be pulled onto the board only when its deadline approaches a certain threshold. The goal is to make the prioritization policy explicit and visible, ensuring predictable workflow prioritization across the different types of WIP.
That breakdown of the Classes of Service is really helpful for managing priority! But doesn't the use of the Expedite class inherently destabilize the system's Cycle Time predictions for Standard work if used too frequently, even if it has a low WIP limit? What is the recommended metric or practice in Kanban to monitor and control the frequency of expedited work to ensure it remains a true exception and doesn't become the norm, thus protecting the long-term predictability of the software development team?
Classes of Service like Expedite and Fixed Date help manage diverse WIP by defining explicit prioritization rules. This prevents critical work from getting blocked and helps maintain a predictable overall Cycle Time for software development.
Also, the Intangible class is often overlooked—it's essential for dedicating capacity to things like tech debt or refactoring, which are necessary for long-term health but often get pushed out by higher-priority Standard work. It maintains balance.
Ethan, you've hit on a critical point about system health. If Expedite items become too frequent, the team's ability to commit to Standard work (and its Cycle Time) erodes. The key is monitoring the percentage of work that falls into the Expedite class—it should be a tiny fraction (e.g., <5%). During your Kanban Flow Review, if this number is creeping up, it signals a deeper problem in upstream processes (like insufficient proactive maintenance or quality issues) that needs to be addressed. The metric itself is the control mechanism for your workflow prioritization discipline.