Kanban Classes of Service
As a Delivery Manager, Product Owner or Service Request Manager you are faced with a myriad of ways to prioritise or sequence work.
In this article we explore what Classes of Service are, how they benefit teams and organisations, and how to implement them across your teams.
What are Kanban Classes of Service?
Classes of Service are perhaps one of the most overlooked and underused concepts in Kanban. They are extremely powerful when deployed in the right way and can greatly simplify the prioritisation of work for a team.
Classes of Service are a set of policies applied to your Kanban system and visualised on your Kanban board. Cycle time and Lead time metrics are recorded for each class of service to form the basis of a decision framework.
Classes of Service simplify prioritisation of work by helping teams to understand when the best time is to start a piece of work and spread the balance of risk across different work types. They provide you with a structured decision framework based on data, fact and evidence.
When combined with Kanban Metrics, Classes of Service become a powerful Risk Management tool.
Classes of Service are deeply rooted in Cost of Delay. Cost of Delay is the economic impact of the delay in delivering a project, feature, or service.
Common Classes of Service
Classes of Service are best understood by looking at them in terms of the Cost of Delay of a work item over time.
Critical and immediate cost of delay; can exceed other Kanban limit (bumps other work); limit of 1 Expedite work item at any given time.
Cost of delay goes up significantly after deadline. Examples of fixed date work may include, work related to regulatory compliance, work required in time for a trade show or conference.
Increasing urgency, cost of delay is shallow but accelerates before levelling out. Standard work items are delivered in a “first in, first out” fashion.
Cost of delay may be significant but is not incurred until significantly later, if at all. Examples of Intangible work item types may include, servicing Technical debt, test automation, or deployment automation.
Benefits of Using Kanban Classes of Service
There are a number of significant benefits to implementing Kanban Classes of Service:
• Reduce the stress associated with prioritisation
• Reduces the risk of stakeholders making decisions based on opinion, emotion or hearsay
• Provides a prioritisation framework based on tangible statistical data
• Improves overall confidence in team predictability
• Better expectation management
How to Implement Kanban Classes of Service
To implement Kanban Classes of Service you’ll need to incorporate some additional visualisations into your Kanban board. It’s very common for classes of service to be implemented using colour coded cards on the Kanban board:
In this example you can see how classes of service are implemented using colour coded work items. Each column has a WIP limit and these are still enforced. Only expedite work items are allowed to blow limits on the board.
If you face the situation where you cannot get to play any intangible work item types, then you can allocate capacity on the board to help with this. Class of Service WIP limits can be applied across the entire board. In the example above we have a board limit of 1 intangible work item type. This can act as a minimum as well as a maximum.
In the next example, we show an alternative method of visualising classes of service by swim lane:
The board is organised into swim lanes to segregate each class of service. You can still implement WIP limits for each class of service in the same way as the previous example.
If you are using an electronic tool such as Jira or VSTS (Azure DevOps) then the best way we’ve found to implement classes of service is to use Tags or Labels. For each work item you simply tag or label it to the required class of service. You can then organise your electronic board by swim lane based on tag/label or colour code cards by tag/label.
Classes of Service for Risk Management
Classes of service combined with lead time distribution charts provides you with a highly effective risk management tool. To use classes of service in understanding delivery risk you need data.
The data you need is Cycle Time data. Collect cycle time data for all work items in each class of service. You can then calculate and plot a lead time distribution chart per class of service. From this we can use the 85 percentile as a confidence indicator and use it to support our conversations with stakeholders.
In the example above, this team delivers 85% of their work items in 33 days or less. If 85% isn’t confident enough for your stakeholders, then you could use the 95th percentile of 40 days or less to manage expectations. It’s all down to appetite for risk.
Plotting your cycle time as a distribution is easy with our free tool.
So how does this reduce risk? Picture this – you’re given a fixed date request. You could de-risk it by starting it immediately if there are no dependencies preventing you to do this. If this was the only fixed date work item, then things would be simple.
In reality however there are often competing priorities. Starting the work too early may prevent the delivery of other more valuable work items.
If you start work too late then you’re snookered – but how do you know when too late is?
Estimated time to deliver is a statistical distribution of your cycle time based on the predictability of your Kanban system for each class of service. Therefore, the distribution chart above indicates that if you want to be 85% certain of delivery by a particular date then you’d better start working no later than 33 days before the deadline.
It’s now time to hold better conversations with stakeholders
If you are a Product Owner, Service Manager, or Delivery Manager tasked with prioritising work and managing expectation then here’s how you need to shape your conversations with stakeholders:
1. When a service request arrives, you need to have a discussion as to which class of service is most appropriate for the work item. Have this conversation backed up by a solid set of lead time distribution charts. This way you can properly manage expectations.
2. Stop prioritising and start sequencing. Talk in terms of work sequencing rather than prioritising.
3. You evaluate what the sequence of delivery should be against other queued up work and insert the work item in the queue accordingly.
About Ian Carroll
Ian is a consultant, coach, trainer and speaker on all topics related to Lean, Kanban and Agile software development.
Connect with Ian at the following