Table of contents
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.
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.
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 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. 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.
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.
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.
Tasks that usually do not have a tangible cost of delay fall under this class. Good example could be maintenance work or technical debt in IT use case. Though, it is worth mentioning that CoD over time for this class can change based on new risks or context updates. See CoD profile below.
While Kanban swimlanes and Kanban classes of service are quite the same based on terminology, we still see a difference from end user perspective, because this has been dictated heavily by 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 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 date. Great, we just agreed on classification. How should we implement that in software? Simple choice would be to use swimlanes just like in the below example.
That will work nicely until you decide that standalone tasks is not ok and you would like to have user story or larger/parent task focus in the same board. It would be great to use swimlanes for higher level task parking and then each swimlane would be used by 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 propostion how and when to separate what is swimlane and what is class of service. In Teamhood we have inveted nested swimlanes or 2 level process or simply an advanced Kanban board!
See the example how things look on Teamhood Kanban board.
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 are decided by looking at service level agreements owned by the team as well as type of tasks that team performs. Based on best practices and experience from working with our customers we have elected the following sets of classes:
Support Team doing Agile (Scrum)
Product Engineering Team doing Agile (Scrum)
Manfucaturing Engineering Team doing Agile (Scrum)
To provide more insights and details 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, support team needs to know when the SLA is broken and how often.
Kanban system with swimlanes for support teams based on MTTR.
This can be a tough one depending if your Kanban software has at least swimlanes feature. If you are still on physical Kanban Board then just draw few horizontal lines to separate classes and your are all set.
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 few months… Unless you are renovating your kitchen and there are not more than 50 tasks.
Of course. 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.