Prioritizing Work Efficiently: Classes of Service in Kanban
Many project managers appreciate the efficiency and productivity benefits of Kanban, but don’t know how best to prioritize tasks. How do you deal with an emergency? How are deadlines and milestones taken into account? When are maintenance tasks carried out?
That’s where Kanban Classes of Service come in. Classes of Service allow you to set up parallel streams within your workflow for different types of tasks – keeping your projects on track without disturbing the standard flow and speeding up crucial tasks when necessary.
What are Kanban Classes of Service?
Classes of Service (CoS) have two main purposes: to classify different work items according to their priority and to clearly define how the items in each CoS should be treated.
As an example, imagine all of your company’s servers go down. Getting back online immediately is an extremely high priority! In contrast, implementing a new feature is a lower priority task. These two work items would be placed in different Classes of Service. This feature was developed early during modern Kanban history to manage tasks with different priority levels.
Kanban Classes of Service group tasks according to their priority – different policies apply to different levels of priority. These policies are determined by the project and team requirements but can include when tasks are pulled into the workflow from the backlog, work in progress limits, and resource allocation.
Types of Classes of Service
Kanban teams can have as many Classes of Service as they require – it really depends on the project in question. To start with, we recommend keeping things simple with the following CoS:
- Standard: Normal work items, features, improvements, etc. The bulk of your work items should be in this CoS.
- Fixed Delivery Date: Work that must be delivered on or before certain dates. This could include important project milestones, compliance tasks, release dates, etc. An example CoS policy would be that Fixed Delivery Date can make up no more than 30% in progress.
- Expedite/Emergency: Tasks that must be taken care of immediately. Normally only one task of this class can be in progress at any one time – emergency tasks should move rapidly through the workflow. Emergency tasks can be pulled in from the backlog even if the Kanban WIP limit has been reached.
Most Kanban teams define Bugs as a class of service – these must be handled quickly and have a priority level between emergencies and standard features. Some Kanban teams include extra classes – a common addition is a Chore or Intangible class. This is used to collect necessary but non-urgent maintenance tasks that often get pushed aside for higher priorities. A Chore CoS item can become an Emergency if it is neglected for a long enough time.
Benefits of using Classes of Service
The main benefit of implementing Classes of Service is that special cases can be prioritized without disturbing your standard workflow. Emergencies, hitting project milestones, and other critical tasks can be handled following established policies – everyone on the team knows what they need to do for each scenario.
Another benefit is the ability to separately calculate the Kanban metrics for each Class of Service. Your target cycle time for emergency items may be 48 hours, while standard features have a cycle time range of 5-7 days.
One common pitfall of using Kanban Classes of Service is that too many tasks can feel like emergencies. When all of your team’s efforts are concentrated on expedited tasks, standard tasks can get pushed down the priority list and neglected. If too many tasks are being classified as emergencies, this is a sign that your team is lacking capacity or that a bottleneck requires additional investigation.
How to implement Classes of Service
The first step to implementing Classes of Service is to decide what your classes should be. We recommend starting simple at first and sticking to the three mentioned above: Standard, Fixed Date Delivery, Expedite/Emergency. You may find later on that you need to add another CoS or two – try different combinations of Classes of Service to find what works best for your project! For Trello Kanban boards, we recommend using Labels to organize your tasks and Classes of Service. You can choose different color labels for each CoS for easy visual reference.
Next, define the policies for how each CoS should be treated. Tasks exist in the same workflow and go through the same steps, however, their Class of Service can affect how quickly they pass through the system. You may need to try different WIP limits until finding the optimum combination for your team. Some teams like to place percentage limits on how many tasks from each CoS can be in progress at any one time. Remember, when in doubt, lower WIP limits are best for productivity.
WIP limits are just one aspect of CoS policy. How do you want your team to approach the different levels of priority? Is it best for all team members to “swarm” an emergency task so it passes through the system as fast as possible, or dedicate one or two members to it? In what cases, if any, can one task interrupt work on another? When should low-priority items be pulled into the workflow? Project managers should think carefully about how best to tackle these questions and be prepared to adjust and improve their process with time.
Have you tried implementing Classes of Service? Which classes did you choose, and why? Tell us about your experience in the comments.
Leave a Comment Cancel reply
Meet the Author
Sonya Siderova is a passionate product manager and a driving force behind Nave, a Kanban analytics suite that helps teams improve their delivery speed through data-driven decision making. When she's not catering to her two little ones, you might find Sonya absorbed in a good heavyweight boxing match or behind a screen crafting a new blog post.
As usual, excellent theme/work. I have a doubt about a certain situation. let’s imagine a situation where I have two major deliveries (fixed dates) and my team at a given time will work on both.
As described in the article, one suggestion is to have a maximum of 30% of the items in the fixed date service class. In this situation, in which I have two fixed deliveries, it would be interesting to have two breaks/divisions to represent these two deliveries, i.e. two areas for a fixed date in the same frame.