Kanban Classes of Service

It is impossible to have a fully functioning Kanban System without Kanban classes of service. In this article we will explain common concepts and use case scenarios for this neat Kanban feature.

What are Kanban classes of service?

Kanban Classes of Service (CoS) are used to classify different types of work based on their priority, urgency or delivery times. A great example in daily life could be the airport security checkpoints, where there are usually at least few types of lanes – regular lanes, priority lanes for families with kids and disabled people, and fast track. By going picking your lane you already have some expectations, you know your situation and what can be done about it. If you are late, you will pay for fast track, if you are on time and you have no issues standing in the queue, you will go for regular lane. Same applies to business processes which throughput work. Kanban system is exactly about organizing and executing planned work, while classes of service help to manage expectations and define structure for process.

Cost of Delay (CoD)

All classes are defined by focusing on the cost of delay. Which helps to measure business impact if something is done later than earlier or first instead of last. It works as a perfect guidance tool when people responsible for work organization need to select priorities for each task.

Typical Kanban classes of service

All classes should be either visually or logically sorted starting to emphasize the order of task execution based on the Cost of Delay (CoD). We list classes by the order of importance down below and encourage you to follow same principle. There are 4 typical Kanban classes of service:

1. Expedite
2. Fixed deadline
3. Standard
4. Intangible

Expedite

Just like the fast track at airports – Expedite class is reserved for high urgency high impact items. Meaning that whenever a task is put into this class specialists who handle tasks must take from this class first. Cost of delay rises fast over time for such tasks. On the other hand, expedite approach without firm control can create a problem if there are too many expedite tasks – your process gets flooded. Resulting in artificial delays for other classes of tasks. A good rule of thumb is to limit capacity of each class, especially expedite. With proper limits there will be safeguards for healthy distribution. Actual limits can be estimated up front and then continuously polished by analyzing how well your team achieves business goals. Common expedite limit is 1.To better understand the dynamics of CoD check the CoD profile over time in the below chart.

Fixed deadline

Another very important class of service is dedicated to tasks which have a deadline. Such tasks become more important overtime so it is beneficial to raise awareness of such items and look thought this list first before turning to tasks in lower classes of service.

These tasks can be ordered based on how close their deadline is. Cost of Delay can jump instantly if deadline is missed. See the CoD profile below.

Standard

Here all the regular tasks should go. Their should be ordered with first in, first out (FIFO) principle. Cost of delay for such tasks grows faster in the early days but then plateaus over time as they have no fixed date or strict urgency. If you will be using limits, this class should be the largest, 50% of full capacity or more can be a fine choice. Check the CoD profile below.

Intangible

Tasks that usually do not have a tangible cost of delay fall under this class. A good example could be maintenance work or technical debt in the IT use cases. Though, it is worth mentioning that CoD overtime for this class can change based on new risks or context updates. See CoD profile below.

Implement Classes of Service

Experience true Kanban application with Teamhood.

Learn more

What is the difference if compared to Kanban swimlanes?

While Kanban swimlanes and Kanban classes of service are quite the same based on terminology, we still see a difference from an end-user perspective, because this has been dictated heavily by the functionality of Kanban software. According to Teamhood views, there is a fine line between classes of service and swimlanes. We suggest that we treat them as separate tools in the Kanban system when beneficial. Let’s imagine a case – Software Development Kanban. The team will have at least two different work item types like tasks and bugs. So that gives us two different classes of service based on work item type – bugs can be urgent or in other words, expedite. Tasks can be either standard or fixed dates. Great, we just agreed on classification. How should we implement that in software? A simple choice would be to use swimlanes just like in the below example.

That will work nicely until you decide that standalone tasks are not ok and you would like to have a user story or larger/parent task focus on the same board. It would be great to use swimlanes for higher-level task parking and then each swimlane would be used for lower-level tasks/child tasks. See the example below.

Example of Kanban Software with classes of service

This can work. But, if you have noticed, we just made a compromise – actual classes of service got mixed with work item types as well as work item hierarchy. That is no longer clean and can confuse.

So here goes our proposition how and when to separate what is swimlane and what is a class of service. In Teamhood we have invented nested swimlanes or 2-level processes or simply an advanced Kanban board!

See the example of how things look on the Teamhood Kanban board.

Kanban classes of service for Agile teams

Question of typical Agile classes of service is quite common due to majority of people who use classes of service come either from Lean or Agile environment, meaning they are experienced and continuously strive for improvements.

Usually, the final set of classifiers is decided by looking at service level agreements owned by the team as well as the type of tasks that the team performs. Based on best practices and experience from working with our customers we have selected the following sets of classes:

Support Team doing Agile (Scrum)

1. Expedite
2. Fixed date
3. Standard

Product Engineering Team doing Agile (Scrum)

1. Expedite (bugs) – this must be limited by Service Level Agreement and severity. If early days, limit by amount of items – good start is 1.
2. Standard aka sprint (tasks/features/user stories)
3. Intangible (tech debt, maintenance) – it is very important to agree on quota of capacity here during every sprint to ensure above classes do not make it impossible to ever start something that is put into this class. This is a prioritized First in First out swimlane.

Manufacturing Engineering Team doing Agile (Scrum)

1. Expedite (support/issues)
2. Fixed date (internal/external agreements among depending teams)
3. Standard (regular project or product work based on sprints)

Example of how support team uses classes of service

To provide more insights and details on how some support teams leverage work classification we will explain one of the most common patterns.

Every support team is required to provide and commit to SLA (Service Level Agreement). Every support team is required to know what is the MTTR (Mean time to resolve) by looking at issue/request properties. Finally, the support team needs to know when the SLA is broken and how often.

Kanban system with swimlanes for support teams based on MTTR.

1. Critical (1-2 hours MTTR)
2. High (up to 1 day MTTR)
3. Medium (up to 3 days MTTR)
4. Low (up to 2 weeks MTTR) (this is usually mapped to sprint length)

Mandatory rules:

• First level support must asses the criticality and then register a ticket in a corresponding class
• Each class should measure mean time to resolve separately
• Kanban system should indicate when SLA is violated to escalate. The higher criticality the more important escalation is

One way to measure MTTR is through Actionable Agile Metrics or Lead/Cycle time.

How to integrate classes of service into your Kanban Board?

This can be a tough one depending on if your Kanban software has at least a swimlanes feature. If you are still on physical Kanban Board then just draw a few horizontal lines to separate classes and you are all set.

Kanban software which supports Kanban classes of service and swimlanes at the same time

This is where Teamhood is called the best Kanban Board in the world. You can have both Kanban System features at the same time and leverage level of detail control alongside work classification. Simple Kanban Boards like Trello, Asana, Jira, Clickup or Monday are oversimplified amateur implementations of Kanban, which become tedious to work with after a few months… Unless you are renovating your kitchen and there are not more than 50 tasks.