Kanban Classes of Service

It is impossible to have a fully functioning Kanban System without Kanban classes of service.

A fully functioning Kanban system relies on the concept of “classes of service” to effectively manage and prioritize work items. Classes of service help categorize different types of work based on their nature, priority, and expected delivery time. Each class of service represents a specific set of rules and expectations regarding how work items should be treated and processed within the Kanban system.

This article 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. The classification system allows teams to promptly identify and address high-priority or time-sensitive tasks, ensuring that critical work receives the necessary attention.

Example:

A great example in daily life could be the airport security checkpoints, where there are usually at least a few types of lanes – regular lanes, priority lanes for families with kids and disabled people, and fast track.

By going to pick 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 the fast track. If you are on time and you have no issues standing in the queue, you will go for a regular lane. The same applies to business processes that throughput work. The Kanban system is exactly about organizing and executing planned work, while classes of service help to manage expectations and define a structure for the process.

How to manage risk with Kanban classes of service?

Managing risk with Kanban Classes of Service (CoS) involves a systematic approach to identify, prioritize, and mitigate risks associated with different types of work items. Here are steps to effectively manage risk using Kanban CoS:

• Identify and assess risks
• Define risk-based CoS categories
• Prioritize high-risk items
• Allocate resources accordingly
• Implement risk mitigation strategies
• Monitor and track risks
• Foster collaboration and communication
• Continuously learn and improve

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 the 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. This means that specialists who handle tasks must take from this class first whenever a task is put into this class. The 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 the 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. The 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 that have a deadline. Such tasks become more important over time, so it is beneficial to raise awareness of such items and look through this list first before turning to tasks in lower classes of service.

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

Standard

Here all the regular tasks should go. They should be ordered with the first in, first out (FIFO) principle. The 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 IT use cases. It is worth mentioning that CoD overtime for this class can change based on new risks or context updates. See the 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 treating 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 items 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 like in the example below.

That will work nicely until you decide that standalone tasks are not ok and you want 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 use each swimlane 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 on 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

The question of typical Agile classes of service is quite common because most people who use classes of service come either from Lean or Agile environments, meaning they are experienced and continuously strive for improvements.

The final set of classifiers for classes of service in a Kanban system is determined by considering the team’s service level agreements (SLAs) and the types of tasks they perform. This analysis ensures that the classification system aligns with commitments and work requirements.

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 the amount of items – a good start is 1.
2. Standard aka sprint (tasks/features/user stories)
3. Intangible (tech debt, maintenance) – it is very important to agree on the capacity quota here during every sprint to ensure the above classes do not make it impossible to 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 a 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). SLAs define response time, resolution time, and other metrics, ensuring timely and satisfactory support. Adhering to SLAs builds trust, enhances customer relationships, and guides resource allocation. Support teams employ strategies to meet SLA commitments and continuously improve their processes.

Besides that, every support team must know the MTTR (Mean time to resolve) by looking at issue/request properties. Finally, the support team must 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
• The 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 tough depending on whether your Kanban software has at least a swimlanes feature. If you are still on the 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 simultaneously and leverage a 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 renovate your kitchen and there are not more than 50 tasks.