Kanban Classes of Service

Struggling to meet deadlines or manage urgent tasks in your team? Kanban Classes of Service is a powerful framework that helps to prioritize work items, reduce delays, and work more efficiently. In essence, it’s impossible to have a fully functioning Kanban System without Kanban Classes of Service.

This article will explain common concepts and use case scenarios for this neat Kanban feature – just to bring some clarity and control to your workflow.

Key Highlights

  • 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.

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 CoS 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.

New to Kanban? Start with our Ultimate Kanban Guide to understand the basics before diving into Classes of Service. 

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: Addressing Urgent Work with Immediate Attention

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: Managing Time-Sensitive Tasks with Clear Deadlines

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: The Backbone of Predictable Flow

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: Handling Low-Priority but Important Work

Tasks that usually do not have a tangible cost of delay fall under this class. An intangible 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.

Importance of Cost of Delay

Before we dive into how to manage risk with Kanban Classes of Service, it’s important to understand the concept of Cost of Delay (CoD). This principle helps teams evaluate the business impact of delaying a task, guiding prioritization across classes of service.

So, all classes are defined by focusing on the CoD. 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.

How to Manage Risk with Kanban Classes of Service?

With a clear understanding of Cost of Delay, teams can now apply Kanban Classes of Service to manage risk more effectively. Here’s a step-by-step approach to doing that:

Managing risk with Kanban 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

Kanban Classes of Service: Risk Levels and Cost of Delay Impact

Now let’s look at how different Kanban CoS, with example tasks, their associated risk levels, and the impact on CoD. This helps to understand how each class affects prioritization and the flow of work.

ClassExample TaskRisk LevelCoD Growth
ExpediteUrgent bug fixHighRapid
Fixed DeadlineEvent prep taskMediumJumps near deadline
StandardFeature devMediumModerate
IntangibleRefactoringLowMinimal

Kanban Classes of Service vs. Kanban Swimlanes: Key Differences

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, as shown in the image 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 image below.

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 image 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:

TeamCategoryDescription
Support Team doing Agile (Scrum)ExpediteUrgent issues that need immediate attention.
Fixed DateWork that must be completed by a specific deadline.
StandardRegular tasks or features that follow the sprint cycle.
Product Engineering Team doing Agile (Scrum)Expedite (bugs)Critical bugs, handled within the constraints of the Service Level Agreement (SLA) and severity. A good starting point for early stages is 1 item.
Standard (tasks/features/user stories)Regular work such as new tasks, features, or user stories handled in sprints.
Intangible (tech debt, maintenance)Tasks related to technical debt or ongoing maintenance. Capacity quotas should be agreed upon during each sprint. Managed using a FIFO (First In, First Out) swimlane.
Manufacturing Engineering Team doing Agile (Scrum)Expedite (support/issues)Urgent support or issues that require immediate resolution.
Fixed DateWork with specific internal or external deadlines, based on agreements with dependent teams.
StandardRegular projects or product work scheduled based on sprints.

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

Aligning the Kanban system with a clear understanding of the customer service level helps ensure customer expectations are met effectively.

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.

The Best Kanban Software

Teamhood stands out as the best Kanban board because it allows you to use both Kanban System features and work classification together with precise control over task management.

Unlike basic tools like Trello, Asana, and Jira, Teamhood offers advanced features such as nested swimlanes and true class-of-service support, providing greater flexibility and functionality for managing your workflow.

Implement Classes of Service

Experience true Kanban application with Teamhood.

Learn more

kanban board tools

Frequently asked questions

  • Can I define my own classes of service?

    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.

  • Which Kanban tool supports swimlanes?

    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.

Teamhood uses cookies, to personalize content, ads and analyze traffic. By continuing to browse or pressing "Accept" you agree to our Cookie Policy.