Class of Service | Agile Scrum Master
Class of Service is a Kanban practice that groups work items into categories based on urgency and cost of delay, then applies different pull and handling policies to each category instead of treating all work the same way. It exists because urgency is not uniform: some items lose value gradually while others lose value suddenly or after a fixed point. Common archetypes include Expedite, Fixed Date, Standard, and Intangible, each defined by a different cost-of-delay shape rather than by subjective importance, giving teams an explicit, evidence-based way to decide what to pull next.
What Class of Service solves
Class of Service exists because not all delayed work costs the same. Kanban treats urgency as a property that can be reasoned about rather than argued about, and Class of Service is the mechanism that makes that possible. Instead of every work item competing for attention on the strength of whoever is loudest, work is grouped into categories that share a similar pattern of how their cost of delay behaves over time, and each category gets an explicit pull and handling policy.
Class of Service turns urgency into a design decision made in advance, rather than a judgment call repeated every time someone asks "can this go next." Because the categories and their policies are agreed before the pressure of a specific item, teams can respond quickly to genuine urgency without letting every request become an emergency.
Why cost of delay drives the categories
Class of Service is built around Cost of Delay, the idea that different items lose value at different rates and in different shapes as they wait. An item with a steady, gradual cost of delay can tolerate some queueing. An item whose cost of delay stays flat for a while and then jumps sharply past a certain point behaves very differently, even if both items feel equally important on the day they are requested. Grouping items by the shape of their cost-of-delay curve, rather than by subjective importance, gives Class of Service its evidence-based foundation.
Common Class of Service archetypes
Several archetypes recur across most Kanban systems, since they map to genuinely different cost-of-delay shapes rather than to any one industry or team:
- Expedite - work where delay carries a severe, immediate penalty, so it interrupts normal flow and is pulled ahead of other work with minimal delay.
- Fixed Date - work with a low cost of delay until a specific date, after which the penalty for missing it rises sharply, so scheduling accounts for the deadline rather than treating the item as routine until the last moment.
- Standard - the most common category, where cost of delay rises roughly steadily the longer the item waits, and the main goal is keeping average wait times predictable.
- Intangible - work whose cost of delay is unclear or hard to quantify, often improvement or investment work, which risks being deprioritized indefinitely unless it is given deliberate space in the system.
Teams do not need to adopt all four archetypes, and some contexts define their own categories. What matters is that each category reflects a genuinely different cost-of-delay pattern, not simply a different label for the same behavior.
How Class of Service shapes pull decisions
Once classes are defined, they change how a team decides what to pull next. Expedite items typically bypass normal queueing and may temporarily exceed a WIP Limit because the cost of not acting immediately outweighs the cost of a temporary flow disruption. Fixed Date items are scheduled with the deadline in view rather than left to compete purely on arrival order. Standard items are usually handled first-in-first-out or by a simple priority rule, since the goal is predictable average performance rather than individual optimization. Intangible items often need a reserved allocation of capacity, since without one they consistently lose out to work with a clearer, more immediate cost of delay.
This is different from simply ranking every item from most to least important. A single ranked list collapses distinct urgency patterns into one dimension and tends to let whoever escalates loudest win, which is exactly the outcome Class of Service is designed to prevent.
Class of Service and flow
Class of Service also affects how a team reads its own flow data. Cycle Time and Throughput measured across all work combined can hide the fact that Expedite items behave completely differently from Standard ones. Segmenting these measures by class of service, an idea used directly in Little's Law and in Aging Work In Progress analysis, gives a much more honest picture of whether the system is performing well for each type of demand rather than averaging away real differences.
Designing classes of service for a specific context
Class of Service is typically defined as part of designing a Kanban system for a specific service, since the right categories depend on what kind of work actually flows through it. This is one of the questions addressed directly inside STATIK, where identifying classes of service is a dedicated step that comes after understanding demand and before designing the board itself. A class of service that is invented in isolation, without checking it against real demand patterns, usually ends up either too coarse to be useful or too granular to apply consistently.
Common misuse and fake-agile patterns
Class of Service is frequently reduced to a label rather than a real policy. Typical problems include:
- Everything is Expedite - so many items get marked urgent that the category stops meaning anything, and normal flow for genuinely standard work collapses under constant interruption.
- Classes without policies - items are tagged with a class of service but nothing about how they are pulled, scheduled, or limited actually changes, so the categorization is cosmetic.
- Intangible work starved indefinitely - improvement and investment work is classified as Intangible but never given reserved capacity, so it is silently deprioritized forever in favor of anything with a more visible deadline.
- Classes based on requester seniority - urgency is assigned based on who is asking rather than the actual shape of the cost of delay, which reintroduces the exact politics Class of Service is meant to remove.
The fix in each case is the same: tie every class to an observed cost-of-delay pattern, attach a real policy to each class, and check periodically whether the categories still match how work actually behaves.
Class of Service is a Kanban practice that categorizes work by urgency and cost of delay so pull decisions reflect real priority