What are Kanban Classes of Service?
According to the creator of the Kanban method David Anderson, classes of service are a highly configurable, very versatile tool for coping with uncertain and unpredictable situations. More precisely, a class of service is a set of policies, which determine how something should be treated.
With their help, you can manage risk in a couple of ways:
- By improving the predictability of lead time for high-risk items
- By making the process of managing dependencies less difficult
To elaborate on that, it is important to note that in a Kanban system, a class of service typically determines the priority of selection of a work item or a project (depending on the scale of implementation) and how quickly it will flow across your board.
Improving the predictability of lead times
In case you are new to Kanban, you must understand that flow efficiency is one of the most important metrics in lean management.
It is the ratio between value-adding time and the lead time required to complete a process. Lead time is the time frame between a customer requesting a service/product and the moment it is delivered. Value-adding is the time your team spends actively working on delivering that service/product.
Most companies have very low efficiency. You might be surprised to hear that the commonly-reported ratio is between one to five percent at the start. This means more than 90 percent of the time required to deliver a project is wasted on waiting for something, which greatly increases the risk of delay.
Classes of service allow you to define service level expectations and establish agreements for each class of service you provide. By defining ones, you give some items more priority and reduce waiting times in the workflow, making the final delivery more predictable.
As a result, you can enjoy greater predictability of how long it would take you to finish a project with a specific CoS.
For example, think of how airlines treat passengers depending on the type of ticket they’ve bought. The more expensive ticket you purchase the higher class of service you get. This comes with a variety of benefits like quicker boarding, more spacious seat, better food, etc.
In this case, each passenger is a work item for the airline. The path from requested to done goes through multiple stages like checking in, onboarding, traveling, etc. When a passenger is qualified for a higher class of service, she spends less time waiting to move through the process and enjoys a better service.
Therefore, the lead time required for her to receive the final deliverable is significantly reduced and the quality is better compared to those with the lowest class of service tickets.
Making the process of managing dependencies less difficult
Kanban classes of service allow you to manage dependencies according to the cost of delay (CoD) for each project. Just to be on the same page, CoD is the economic impact of failing to deliver your product or service on time or simply said – the amount of money you will lose by delaying the delivery. By calculating CoD you can understand the importance of delivering your projects on time.
The logic is simple. When the cost of delay is small or there’s sufficient time to start early, then, there’s no need to manage dependencies explicitly. You can just let them emerge and manage them dynamically.
However, when the CoD is high, you need to plan your capacity in a way that will allow you to start early and complete the project with greater efficiency, even if it results in delaying other projects with lower costs of delay.
To elaborate further into what we’ve laid out so far, let’s dig into the typical Kanban classes of service.
Types of Kanban Classes of Service for Risk Management
Kanban defines 4 classes of services for risk management:
Let’s explore the processing policies related to each of them and see some examples.
Expedite is the highest Kanban class of service. It is reserved for work items/project with a critical priority and very high cost of delay. When something is qualified as an Expedite CoS, it requires 100% devotion from your team.
Work items in this class come with a huge risk for your project. To deal with them you must leave everything else in progress and allocate all the necessary capacity to deliver them within the service level agreement.
An example of an Expedite class work item is fixing a website that is unreachable. Your goal is to aim for 100% flow efficiency and get it back online as soon as possible without accruing wait time.
Such work items usually go through shorter workflows containing only the most vital steps. It is important to note that to make the most of this class of service, you should apply it only to work items that tolerate absolutely no delay.
Fixed delivery date
The second most important Kanban class of service is dedicated to assignments with a fixed date and a high cost of failing to deliver on time. An example of such an item would be preparing a minimum viable product by June 6 that comes with a clause, which allows your customer to pay a lower price if you fail to do so.
Projects that qualify for this class require detailed forecasting and careful consideration before commitment. We advise you to implement techniques such as Monte Carlo simulations in the process of negotiating the delivery date.
They will allow you to run a large number of random simulations based on previous performance to give you probable delivery time frames in order to minimize the risk of failing to deliver on time.
It is a common practice for assignments from this Kanban class of service to become Expedite if they are falling behind and are in danger of breaking the service level agreement.
The majority of tasks in your workflow should qualify as standard. This class of service is reserved for items with a moderate cost of delay and tolerate long lead time.
Standard class work items don’t require much prioritizing. We advise you to process them on the principle “first-in-first-out” when pulling them in progress.
Please note that when the cost of delay of your projects or tasks is homogeneous, relying on Standard class of service as a single one is preferred. This is because classes of service usually serve the most important class pretty well but that’s not true for the least important things.
As a result, some of the low CoS items can take a very long time to complete due to priority overrides by higher CoS items. When some of the items take 2 days but others take 200 days, the probability distribution will be much wider and will harm the forecast.
Work items from this class of service can be considered as “chores”. You know you have to complete them but there’s no rush for processing them right away. Such assignments come with little to no cost of delay and allow very long lead times.
When prioritizing work, intangible tasks must come last. They are the place from which you are most likely to relocate capacity if an Expedite task arrives. Still, it should be noted that if an intangible item remains unprocessed for too long, it may create the environment for generating Expedite class assignments.
An example of that would be postponing security optimizations on a website. Initially, they seem like a chore. Eventually, if you get hacked due to outdated security measures, you will have an Expedite work item related to putting the situation under control as soon as possible.
Custom classes of service
The four Kanban classes of service discussed so far can serve as a guideline, but you are free to define your very own according to risk. For example, in a software development context, it is a common practice to define a 5th class called Bugs, which is usually placed between the Fixed delivery date and Standard CoS.
Another viable option not limited to IT is proposed by the Lean coach Thorbjørn Sigberg. It is called Urgent and is suitable for teams that struggle with decomposing and decoupling work because it gives them the opportunity to give greater priority to unplanned assignments without expediting them.
He suggests using this CoS for small requests like changing a text on a webpage that would otherwise “drown” in the Standard class.
Once again it should be placed between the Standard class and the Fixed delivery date one.
Still, these are just examples. You can customize classes of service in any way to fit into your context.