Kanban Principles and Classes of Service
The Answer
Kanban principles come in two sets that are often collapsed into one. Four change management principles govern how you introduce kanban: start with what you do now, agree to pursue incremental change, respect current roles and titles, and encourage leadership at every level. Three service delivery principles govern how you run it: understand and focus on your customer’s needs, manage the work rather than the people, and evolve policies to improve outcomes. The six practices sit underneath both and are where the day-to-day work happens, starting with visualising the workflow and limiting work in progress. Classes of service, which most summaries skip, are how a board handles different kinds of urgency without anyone shouting.
The Four Change Management Principles
These describe how to introduce kanban to a team that already has a way of working. They exist because process change usually fails on adoption, not design.
Start with what you do now. Map the process you actually run, including the awkward waiting states nobody likes to admit to. Designing a target process first is the standard mistake, because you end up improving a workflow that does not exist.
Agree to pursue incremental, evolutionary change. Small changes that survive contact with a busy week beat a redesign that gets abandoned. This also lowers the stakes of getting one wrong.
Respect the current process, roles, responsibilities and job titles. Nobody’s title changes, which removes most of the political resistance a rollout attracts. Contrast this with a scrum adoption, where restructuring who decides what is usually the hardest part.
Encourage acts of leadership at every level. The person who notices that review is where cards go to die is usually not the person running the meeting.
The Three Service Delivery Principles
Added later to the method, these describe how to operate the system once it is running.
Understand and focus on your customer’s needs. The unit of value is what the customer receives, not what the team produced. A board full of finished sub-tasks that shipped nothing is a board that is measuring the wrong thing.
Manage the work, let people organise around it. Assign work to the board, not to individuals in advance. People pull what is next when they have capacity, which is what makes the WIP limit bite.
Review the network of services regularly and evolve policies to improve outcomes. Policies are meant to change. Treating them as fixed is how a team ends up defending a rule that made sense eighteen months ago.
The Six Kanban Practices
| Practice | What it means in a working week |
|---|---|
| Visualise the workflow | One column per real stage, one card per item, waiting states included |
| Limit work in progress | A numeric cap on the columns where work collects |
| Manage flow | Watch how work moves, not how busy people look |
| Make process policies explicit | Written rules for done, pull and escalation |
| Implement feedback loops | Regular reviews, from a daily standup to a quarterly look at strategy |
| Improve collaboratively, evolve experimentally | Change one thing, measure, keep or revert |
The second practice is where most of the value sits, and it is also where most teams stop short: boards with no caps on them are extremely common, and a board with no caps behaves like a to-do list arranged sideways. WIP limits covers setting a first number and tuning it.
Classes of Service
A class of service is a category that tells everyone how a work item should be treated, agreed in advance so nobody has to argue about it in the moment. Most summaries of kanban skip classes of service entirely. Which is a shame, because this is the mechanism that stops a board being run by whoever complains loudest.
The four conventional classes:
- Expedite. Drop everything. The cost of delay is immediate and severe, typically a production incident. Convention is one expedite slot on the board, and pulling it means something else stops.
- Fixed date. Has a real external deadline, such as a regulatory filing or a contracted launch. Scheduled backwards from the date rather than pulled by priority.
- Standard. The default. Pulled in queue order, first in first out, and this should be the large majority of items.
- Intangible. No immediate customer value and real long-term cost if ignored. Technical debt lives here. Pulled when there is slack, which is why teams that never have slack never pay it down.
In practice each class gets a colour or a swimlane, and the policy is written somewhere everyone can see it. The cap on expedites is what makes the whole thing work: one at a time, and taking it means the team stops something else. A board carrying three simultaneous expedites has no classes of service. It has an interruption problem with better labelling.
Making Process Policies Explicit
Explicit policies are the least glamorous practice on the list, and the one that saves the most arguments over a year. Four are worth writing down before anything else:
- What “done” means for each column. Does a card in Review mean review has started, or that it is waiting for someone to pick it up? Teams disagree about this more often than they realise.
- Who pulls, and when. Anyone with capacity, or only certain roles.
- How urgent work enters. Which is where classes of service earn their place.
- What the WIP limits are and what happens when one is hit. Usually: help finish something in that column before starting anything new.
Write them on the board itself where you can. A policy living in a document nobody opens is an unwritten policy with extra steps, and it will be applied inconsistently by people who each remember a different version of it. Put it where the work is.
How the Principles Show Up on a Real Board
These sound abstract until a board contradicts one of them. Then they are very recognisable.
Assign every card to a named person at planning time and you are managing people, so the WIP limit quietly stops meaning anything because everyone is working from a private queue that the board cannot see. Expedite three items a week and the expedite class has become the default, which is an intake problem wearing a policy’s clothes. Redesign your columns to match a template and the board now describes somebody else’s work.
Cheapest diagnostic I know: stand in front of a board and ask what happens next to the oldest card in the busiest column. If nobody can answer without going to find one specific person, the policies are not explicit yet, whatever is written on the wall. For where these principles came from and how they fit together, the kanban method covers the origins and the starting steps.
FAQ
How many kanban principles are there?
Seven in total, though it depends on which source you read. Four change management principles cover how you adopt kanban, and three service delivery principles cover how you run it. Older material lists only the first four, which is why the number varies.
What is the difference between kanban principles and practices?
Principles are the beliefs that shape how you introduce and operate the system, and practices are the six concrete things you do. Principles explain why you would respect existing job titles, and practices tell you to put a cap on the review column.
Are classes of service mandatory?
No, nothing in kanban is mandatory. They become worth adding once a team is regularly interrupted by urgent work, because they replace an argument about priority with a rule agreed in advance.
What are kanban’s core values?
Nine values are associated with the method, including transparency, balance, collaboration, customer focus, flow, leadership, understanding, agreement and respect. They are less widely used than the principles and practices, and I would learn the practices first.