A quick Step-by-Step tutorial that will help you get started with Kanban and manage projects with ease in Kanbanize.
Kanban Classes of Service is a highly configurable, versatile tool for managing risk that allows Agile teams to prioritize work in the most effective way.
According to David Anderson, the creator of the Kanban method, Kanban Classes of Service (CoS) is a highly configurable, versatile tool for coping with uncertain and unpredictable situations. More precisely, a class of service is a set of policies that help Agile teams determine how to prioritize work items and projects.
Managing projects, you have probably experienced the trouble of navigating through changing customer requirements, new stakeholder requests, capacity fluctuations, and countless other surprises that put the successful delivery of your project at risk. If the answer is yes, then you know how important it is to prioritize work to minimize risk effectively.
In a Kanban system, a class of service typically determines the priority of a work item or a project (depending on the scale of implementation) and how quickly it will flow across your board. Choosing to introduce Kanban Classes of service allows Agile teams to define service level expectations and establish agreements for each class of service they provide.
This way they can manage risk by:
Lead time is the time frame between a customer requesting a service/product and the moment it is delivered. Another essential metric here is “Value-adding time”, or the time your team spends actively working on delivering that service/product. The ration between value-adding time and the lead time gives you your flow efficiency (one of the most important metrics in Lean Management).
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. This greatly increases the risk of delay.
By defining Kanban Classes of Service, agile teams give certain work items or projects more priority than others. This, in turn, reduces the waiting times in the workflow for the high priority items and makes their final delivery more predictable.
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.
Kanban classes of service allow you to manage dependencies according to the cost of delay (CoD) for each project. 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, 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.
10 Years Kanban Experience In 1 Free Book:
To elaborate further into what we’ve laid out so far, let’s dig into the typical Kanban classes of service.
Generally, 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/projects with a critical priority and a 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. Such work items usually go through shorter workflows containing only the most vital steps.
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 an MVP (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 committing. 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.
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, that tolerate long lead time and don’t require much prioritizing. We advise you to process them “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.
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. It allows them to give higher 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.
And Optimize Your Workflow.
Kanban classes of service allow you to minimize risk by improving the predictability of your workflow and managing dependencies easier. Practically, they are sets of policies that guide you and your team when prioritizing new work.
Kanban defines 4 classes of service, but you are free to customize them and add new ones according to your needs.
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.