In any project, work items need to be prioritised above others. Classes of Service (CoS) are a way of setting up parallel workflow streams in Kanban projects to handle tasks with different levels of priority.
For Classes of Service to work correctly, however, you must set Kanban rules on how different classes should be treated. So what does this mean for you and your team in practice?
Prioritisation
The first step to implementing Kanban rules is to define your Classes of Service and their priority levels. You could define your own classes of services depending on your project. Most Kanban teams have between three and five. Some popular CoS are:
- Emergency/Expedite: Critical systems going down, unexpected serious glitches and last-minute change requests will naturally be treated as high priority.
- Fixed Delivery Date: Key handovers, release dates and other deadlines. Tasks with a fixed end date that is not likely to change and where the impact of a delay is high.
- Bug: Bugs must be corrected with higher priority than new functionality.
- Standard: Regular workflow tasks, neither especially high nor low priority.
- Intangible/Chore: This class covers those tasks that are not urgent but could be maintenance or small upgrades – minor UI updates or code refactoring.
It’s important to note that Classes of Service don’t have to be static. A chore task or a fixed delivery date task can easily become emergencies if they are neglected for too long. This list is a common way for Kanban teams to order CoS by priority and a good starting point, but your team may have different needs. In some projects, a bugs class could be unnecessary. In others, it should be prioritised above fixed delivery date tasks.
Contribution to flow
What happens when everything is an emergency? When high-priority tasks come up at high frequencies, lower-priority tasks often get pushed aside and forgotten. If your team keeps neglecting the low priorities, sooner or later they will turn into issues.
The way to deal with this phenomenon is to make Kanban rules about how Classes of Service contribute to the overall flow and set individual WIP limits for each class.
It is very common to only allow one emergency task to be in play at any one time in order to maintain team focus. Optimum WIP limits for the other Classes of Service are far more flexible. A practical way to set WIP limits is to divide tasks according to their flow contribution.
Agreement
It is important to make Kanban rules explicit policies, so that your team knows exactly what is expected of them. In fact, it is one of the six Kanban best practices. Convey new or updated policies to your team as soon as possible during regular Kanban meetings, and encourage feedback – you never know what insights might come up!
Make sure that everyone is in agreement on team behaviour towards different Classes of Service. Do all team members swarm an emergency, or just those working on standard or chore classes? Which tasks can be interrupted, and which can not? At what level of priority should people be brought in from another process or team? For projects with many classes and complex Kanban rules, we recommend plotting out a project management flowchart for clarity.
Practice as many scenarios as needed with your team. This will help find out what rules bring out the highest productivity from your team. Especially, when the pressure is high and you need to make sure your team is comfortable and your critical priorities are taken care of first.
Improvement
Kanban relies on incremental improvement. Make sure to individually track the Kanban metrics for each Class of Service. A cycle time of 5 days may be fine for a standard class task, but a terrible response to an emergency. Comparing cumulative flow diagrams for each Class of Service makes it easy to see which areas are doing well and which are having issues and falling behind.
Don’t be afraid to tweak the Kanban rules to make your process more efficient. You might want to reorder the priority level of certain classes, or change the percentage of how much each class contributes to the overall flow. However, we recommend not making too many changes too quickly – it makes it harder to identify what works and what doesn’t. Implement a change, track throughput and cycle time for a few iterations, then use the data gathered to drive the next decision.
Explicit Kanban rules reduce the risk of productivity breakdowns and escalations of work items. The more explicit you make the policies, the more comfortable your team is to make their own decisions. Your team will become more self-managed and the workflows will function more efficiently. Use in-depth observation of the results to gain important insights on how to continuously improve your policies.
What Kanban rules have you implemented? How has that affected your process efficiency? How have you changed your policies to make them work better? Tell us about your experience in the comments!
