Classes of Service: How to Let Urgent Work Through Without Wrecking the Queue

Introduction

Every team has a priority field, and on every team it is a lie by Thursday. It has four values, three of them mean urgent, and the fourth is where work goes to be forgotten. Somebody adds "critical" above "high" to win an argument, and six weeks later half the queue is critical.

Classes of service are the fix, and they are usually explained badly: four coloured swimlanes and a page of policy. The useful idea underneath is smaller. A class of service is a statement about how the cost of being late behaves, not about how much somebody wants it.

Priority asks who is shouting. A class of service asks what happens to the value of this work if it ships three weeks from now. The second question has an answer you can check, which is why it survives contact with a Thursday.

Cost of Delay, in Four Shapes

Work does not lose value at one uniform rate. It loses value in one of roughly four shapes, and those shapes are the four classes. The names come from Kanban practice, and the only thing that matters about them is the shape each one describes.

Expedite. The cost of delay is immediate and steep. Payments are failing right now, the signup form is down right now. Every hour costs something real. This work justifies interrupting work in flight.

Fixed date. The cost of delay is near zero until a specific date, then it falls off a cliff. A regulatory deadline, a conference demo, a contract milestone. Shipping three weeks early buys little. Shipping one day late costs everything.

Standard. The cost of delay is real and gradual. Most product work is this. Sooner beats later, and the difference between Tuesday and the following Monday is not dramatic. This should be the overwhelming majority of your queue.

Intangible. The cost of delay is near zero now and large later. Dependency upgrades, the test skipped for four months, the deploy script only one person understands. Nothing breaks this week. Something breaks eventually, expensively and at the worst moment.

Two of these four are not urgent at all, and the fourth, intangible, is the class a priority field cannot express: there is no value of "priority" that means "zero cost today, ruinous cost in nine months". That work sits at the bottom of a priority-sorted list forever, which is exactly how it becomes an incident.

The Four Classes, Side by Side

The share column is the part teams skip, and it is the part that does the work. A class with no cap is just a label, and labels inflate: if anything can be an expedite, everything becomes one.

The Expedite Lane Is a Budget, Not a Label

The sentence to take away: an expedite lane with no limit is not a lane, it is permission.

The mechanic that makes expedite work is a cap on how many can be in flight at once, and for a small team the honest cap is one. One expedite at a time, for the whole team. If a second genuine emergency arrives while the first is still open, that is not a scheduling problem to solve with a bigger lane, it is information: either the first one was not really an expedite, or something upstream is generating emergencies and that is the thing to fix.

A cap of one also makes the cost legible at the moment of the decision. Expediting means a named piece of work in flight ships later. That is a trade, and trades are fine. What is not fine is making it invisible, which is what a priority field does: the queue reorders, nothing records why, and the displaced item quietly ages, and item age shows it plainly.

One more rule, and it is the one teams resent: an expedite does not get to skip the readiness bar. Urgency is a reason to start something first. It is not a reason to ship something untested. The class of service changes the order of the queue, never the definition of done.

Where This Goes Wrong on Small Teams

Four lanes for four people. The literature describes classes of service for departments of fifty, with per-lane limits, buffer columns and a policy document. A team of five implementing that spends more time classifying work than doing it. At small scale you need two decisions, not four lanes: is this an expedite (almost never), and is this intangible work that will never be taken unless we reserve time for it (more often than you think).

Treating fixed date as urgent. The most common and most expensive mistake. A fixed-date item with six weeks of runway is the least urgent thing in your queue today. Pulling it ahead of standard work costs real delivery and buys nothing, because shipping five weeks early has no value. What it needs is a start date worked backwards from the cliff, then no special treatment until that date arrives. Teams that expedite fixed-date work are usually managing anxiety rather than cost of delay.

Expedite as an escalation route. If marking something expedite is how a stakeholder gets attention, the classification stops describing cost of delay and starts describing organisational position. The tell is that expedites cluster around one person rather than one kind of failure. The fix is upstream, at intake, not in the lane.

How This Works in FlowBoard

FlowBoard has no swimlanes, because it has one continuous flow rather than a board of columns. Classes of service live in the thing that decides what gets taken next: the order of that single list.

The flow is sorted by a priority score, and that score comes from a formula you can edit. The default is deliberately plain, impact plus clients plus technical ease, and you can add your own numeric fields to it. That is where a class of service belongs: add a numeric field for cost of delay shape, give it a weight, and the classification stops being a label somebody reads and becomes an input to the ordering.

When the class is a weight in a formula, reprioritising means changing one input and the list reorders itself consistently. When it is a label, it means a human remembering a policy, which they do accurately for about two weeks.

For the visible marker, tag groups give you a named, coloured set of tags, so "expedite", "fixed date" and "intangible" can be one group that renders on the item. The tag is for humans reading the flow, the numeric field is for the ordering, and keeping those jobs separate is why the ordering stays trustworthy.

Readiness stays independent of all of it. An item carries its own red, amber or green state, and an expedite that is red is not shippable just because it is first. The class changes position in the queue, not the bar for done.

Fixed-date work uses the due date rather than the class, which is the right tool for a cliff. Nothing about an expedite needs its own release or its own process. It is the same flow, taken sooner.

Frequently Asked Questions

What are classes of service in Kanban?

Classes of service are categories that describe how the cost of being late behaves for a piece of work, and they carry a handling policy for each category. The usual four are expedite, fixed date, standard and intangible. They differ from a priority field because they describe the shape of the cost of delay over time rather than how much somebody wants the work.

What is the difference between a class of service and a priority?

A priority is a single ordering of desire, so it compresses everything into one axis and inflates over time. A class of service describes how value decays, which means two items can be equally important and still need completely different handling: a fixed-date item with six weeks of runway and a production outage are not comparable on one scale.

How many items should be in the expedite lane at once?

For a team under about fifteen people, one. The cap is the mechanism, not the lane. A second simultaneous expedite usually means either the first was not genuinely urgent or something upstream is manufacturing emergencies, and both of those are worth discovering rather than absorbing.

Do small teams need classes of service at all?

Most teams of five need two of the four: a capped expedite path for genuine emergencies, and a reserved slice of capacity for intangible work that would otherwise never be taken. Fixed date is handled by a due date, and everything else is standard. Implementing all four with per-lane policies at that size costs more than it returns.

Where does technical debt fit?

Intangible, which is why it never ships. Its cost of delay is near zero this week and large later, so it loses every comparison against work with a visible cost today, every week, forever. The only thing that reliably moves it is reserving capacity for it rather than hoping it wins on merit. See handling urgent requests without derailing the week for the intake side of the same problem.

What to Do This Week

Do not introduce four lanes. Run one audit instead, and it takes about twenty minutes.

Take the last ten things that were called urgent and sort them into the four shapes. Most teams find one genuine expedite, three or four fixed-date items pulled far too early, and the rest standard work somebody escalated to get it moving. That distribution is the finding: the expedites were not the problem, the fixed-date items taken five weeks early were, because each displaced standard work for no gain.

Then pick your cap. One expedite in flight, team wide, written somewhere people will see it. You do not need a policy document for the other three classes yet, and you may never.

Next: what a pull system actually changes, because classes of service only function when people take work rather than receive it, and how to set a work in progress limit without turning into a process team, since the expedite cap is just that idea applied to one class.