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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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)
Product Engineering Team doing Agile (Scrum)
Manufacturing Engineering Team doing Agile (Scrum)
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.
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.
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.
The answer is yes. There is no firm restriction what properties of work should be used to group work tasks into classes of service. Though original idea of priorities and delivery dates has been proven and polished by numerous professionals. Sticking to it is always a good rule of thumb.
Teamhood is the only tool which can offer both swimlanes and classes of service at the same time. This unique combination allows your team to visually organize tasks and prioritize them based on importance and urgency. It simplifies workflow management and improves productivity.