When it comes to knowledge work, the type of items that teams get to work on varies in urgency, requirements, perceived business value and level of priority.
For example, a software development team has just gone live with their application. The team is now expected to work on both enhancements and maintenance work. At the start of the workday, they are scheduled to work on features for a planned release version and a few minor production issues. Midday comes and a security vulnerability has been reported, putting client data at risk. The team focuses attention to the production issue and works on it immediately. If this affects the teams work capacity, other work items might be halted to address the critical issue.
This is much similar to the medical triage concept being used in the emergency department of hospitals. The triage nurse assesses each patient that arrives. Based on the severity of their condition, the triage nurse determines the order of patient treatment. A patient suffering from cardiac arrest will be considered a higher priority than a patient with a tummy ache.
Establishing a set of rules that govern how incoming work is treated enables teams to work in the best interest of the customer. Teams will also decrease the amount of time a task remains in the backlog.
That is what Kanban classes of service aim to provide.
Classes of Service Explained
Kanban classes of service provide structure and governance for how teams should handle incoming work. According to David Anderson, author of Kanban: Successful Evolutionary Change for Your Technology Business, a class of service (CoS) is a set of policies that describe how an item of work should be treated. Anderson also emphasized that classes of service should be set according to customer expectations. This means that teams should classify work based on the customer’s perception of the item’s value and the team’s performance. When an item of work enters the team’s workflow, it will need to be classified according to the set of policies that apply to it.
Anderson suggests four classes of service that teams can use to classify work items coming into their workflow. Let’s explore these various CoS and what policies are inherent to each of them.
Expedite
This class of service is for critical and top priority items that require immediate handling. An expedite item preempts other work and requires teams to ensure no interruptions are experienced in the workflow. The WIP limit for this class is set to one, but in the case where too many expedite items need solving, the WIP limit for this class may be increased. This may mean that work done for other classes of service would have to give way. When this happens, team members swarm to get the expedite work items out of the pipeline as soon as possible.
Critical production issues, server breakdowns, network defects, and patches are examples of an expedite item.
Fixed Delivery Date
This class of service is for work items that have a significant cost of delay, if not delivered on a fixed delivery date. Items that fall under this class are prioritized where necessary to be finished on or before the target deadline. If the team falls behind schedule, fixed date items would usually be promoted to expedite in order to speed up the process.
Samples of fixed delivery date items are those related to contractual or regulatory obligations and seasonal business. This also includes projects that are seen to put the product at a competitive advantage when released to the market at a specific date.
Standard
Items that fall under this class of service aim to solve business and customer requirements without a fixed timeline or sense of urgency. Standard work items typically flow on a First In First Out (FIFO) basis.
A good chunk of a team’s work would typically fall under this classification. Some examples are minor enhancements to existing system features, cosmetic bugs, or minor issues that do not hamper major flows in the system.
Intangible
Items that fall under this class of service are those that are useful but do not have a significant cost of delay. Quality improvements and optimization work would normally fall under this classification.
Intangible work items, though non-urgent, can become critical in the long run. For example, unresolved data optimization issues could result in performance problems in the long run and hinder users from performing major workflows in the system. This intangible work item would then be escalated to an expedited one.
While these are the commonly used classes of service, teams are not restricted to use only these four. For example, there are some teams who introduce a specific class of service for bugs. It is recommended though that teams keep their CoS to at most six, as having more than that may just cause confusion.
Cost of Delay
Based on the policies and definitions of the four classes of service, cost of delay is the main determinant when classifying and prioritizing work items. Cost of delay is the perceived economic value of a work item through time. It helps teams understand how the value of an item they are working on can diminish over time.
Teams assess the impact of a delay in delivery of a feature, project, or solution to an issue. Delaying the release of a version of your software which is aimed at giving you a competitive advantage will definitely have a high cost of delay. In the same way, not being able to immediately release a solution to a critical production issue entails a high cost of delay, as you stand to have dissatisfied customers or even lose them because of it.
By using classes of service, teams are able to prioritize work by urgency and value, which exactly what cost of delay is about.
Capacity Allocation
In order for teams to better predict when work items will be delivered, they can allocate capacity per class of service. A sample capacity allocation commonly used is illustrated below:
- Expedite – +5%
- Fixed Delivery Date – 20%
- Standard – 50%
- Intangible – 30%
Expedite items are allocated on top of normal capacity because teams should not plan for or expect critical work items to arrive. As expected, the entry of expedite items into the team’s workflow causes overburden. This is because expedite items do not count against a team’s WIP limit, but instead is an addition to it.
Assume that a team’s WIP limit is 10. By using the capacity allocation suggested, the team will work on the following number of work items per class at any given time:
- Fixed Delivery Date – 2 items
- Standard – 5 items
- Intangible – 3 items
When an expedite item enters, it would increase the WIP limit by 10% for a total of 11 work-in-progress items. When there are many expedite items that need attention, the team must decide if they will forego work for other classes and focus on delivering the expedite items first so that they can normalize things. In this scenario, it would be the intangible class items would become the lowest priority, below standard or fixed date items.
It is recommended that capacity allocation is based on customer demand and when appropriate, on historical data as well. As the team takes in more work, patterns of the workflow will emerge. These patterns can help derive capacity allocation percentages that will work for the team. Teams should review and assess their capacity allocation regularly to best adapt to their current situation.
“What if there is no demand for fixed date items?”
“Does this mean we should take in more standard items instead?”
While there is no set rule for such a situation, it is recommended that the team decide on the best course of action given their current situation. At the end of the day, we want our team to perform at an optimal capacity to keep a stream of work flowing.
Integrating Classes of Service into your team’s Kanban board
Your Kanban board should be able to accurately portray how many items per class the team is working on at one time. Your Kanban board should allow you to specify the class of service for each item using a visual indicator. Even better is when your board has dedicated swim lanes per class of service. This makes it easier for your team to focus on the work being done. Please note that very few Kanban software solutions provide this functionality.
Kanban Zone boards provide teams the ability to designate classes of services in swim lanes. With Kanban Zone, teams can assign color-coded labels for each class of service to easily identify the classification. In addition, boards can be fully customized show their process and also have dedicated swim lanes per CoS.
When a work item is assigned a class of service, teams can use the color coded labels in Kanban Zone based on the CoS assignment. The work items will then flow to their designated swim lanes.
Having the ability to integrate CoS to your Kanban board enables the team to focus more on executing the work and eliminates the think time necessary to determine what to pull next.
Start using our Kanban Classes of Service (CoS) board template to help teams speed up the prioritization of items and improve predictability of work delivery.
