Kanban: What are Classes of Service and Why Should You Care?

My last post, Kanban and When Will This Be Done? was about using Cycle Time to make reliable commitments to the customers of your organization. I talked about prioritizing and swarming as methods of helping meet your Cycle Time commitments. In most organizations, it turns out that not everything has the same level of value or time pressure. Some things need to move through faster than others either because they are needed to meet customer promises or because earlier delivery means more income for the business. Some have to be completed before a specific date due to market or compliance or integration reasons. Still others can be completed in the normal course of the flow of work.

So, we can’t treat everything in a homogenous fashion. But, handling the planning and scheduling to meet the differing levels of time pressure can consume a lot of time and energy. The key is to create a simple and transparent approach for the team to self-organize around the work to meet the needs of the business. This approach should address the inherent variability in the work. The way that we address these differing levels of time pressure is through Class of Service. Class of Service is a mechanism for typing work items and is used to inform team decisions about prioritizing and swarming.

Class of Service Policies

Each Class of Service will have its own policy to reflect prioritization based on the different risks and business value. Classes of service and knowledge of the policies associated with them empower the team to self-organize the flow of work to optimize business value. Used effectively this will result in improved customer satisfaction, elevated employee engagement, and increased trust. A Class of Service policy will include the following for the class of service:

  • how to make the class of service visible,
  • the impact this class of service has on WIP limits,
  • prioritization and swarming agreement for the class of service,
  • estimation requirements for the class of service.

You can use the use card color or a row to visualize the class of service. The row is particularly useful when you are reserving some performer capacity to the class of service. The WIP limit policy may allow for the work item to exceed the column WIP limit, could reflect that there is a maximum of a particular Class of Service, or require a minimum of a Class of Service. Prioritization can include FIFO, Pull Next, or Interrupt Current WIP. Estimation can range from no estimation to a detailed estimate.

Sample Classes of Service

These Class of Service examples are drawn from David Anderson’ book, Kanban: Successful Evolutionary Change for Your Technology Business and personal experience.

Expedite: The Expedite Class of Service can be very disruptive to flow. So I use a lane to protect some capacity against these disruptions and then limit the number of expedites was can have on the board at a time. This allows us to expedite while minimizing the impact on the other Classes of Service. In his Kanban book, David suggests swarming on blockers only. I believe you can swarm on delayed items and expedites, especially if you have left some performer capacity available when you set your WIP limits. This helps maintain the flow through your system.

Many organizations experience a large amount of expediting.This is a sign of low trust in the organization’s ability deliver reliably. So the emotional response is to expedite everything. In my experience, demonstrating an ability to make and keep commitments for the Standard Class of Service will establish trust that overcomes this emotional response. The pressure to expedite decreases dramatically when you are able to make and keep commitments to your organization.

Sample Expedite Class of Service policy:

  • Expedite requests will be shown with white colored cards.
  • Expedite requests have their own row on the Kanban board. The Expedite row has a WIP limit of one.  A limited amount of performer capacity is reserved for Expedites.
  • The column WIP limit can be exceeded to accommodate the Expedite card.
  • Expedite requests will be pulled immediately by a qualified resource. Other work will be put on-hold to process the expedite request.
  • Expedite requests will be T-Shirt sized to set Due Date expectation.

Fixed Delivery Date: The Fixed Delivery Date Class of Service is used when something has to be delivered on or before a specific date. To accomplish this, you will pull the card from the first queue sufficiently in advance of when it needs to be delivered. In the previous post, we suggested you set the policy at the Mean + 1 Standard Deviation. This will result in an 80% likelihood of success. This is likely to be an unsatisfactory success rate. So you will want to do two things. First, increase the policy for Fixed Delivery Date Class of Service items from the Mean + 1 Standard Deviation to the Mean + 3 Standard Deviations. This will increase likelihood to above 99%. Secondly, you should do some more detailed analysis when making this work ready to mitigate the risk that you will deliver this late. If the item is large it may be broken up into smaller items and each smaller item should be assessed independently to see whether it qualifies as a fixed delivery date item.

There is a significant opportunity to misuse this Class of Service when dealing with an organization that is comfortable with a traditional plan driven approach to managing a project. There is a tendency to want to use the Fixed Delivery Date in the same fashion as the tasks on a Gantt Chart. The problem with this is that it will spawn the same destructive behavior that we discussed in my last post (losses accumulate, gains are lost). So only use the Fixed Delivery Date when you have an external due date constraint. Remember the concept of Regression to the Mean and use the Standard Class (discussed next) and flow to deliver to a plan.

Sample Fixed Delivery Date Class of Service Policy:

  • Fixed delivery date items will use purple colored cards.
  • The required delivery date will be displayed on the bottom right hand corner of the card.
  • Fixed delivery date items will be given priority of selection for the input queue based on a the historical mean + 3 standard deviations of the cycle time for tasks of the same size.
  • Fixed delivery date items will be pulled in preference to other less risky items. In this example, they will be pulled in preference to everything except expedite requests.
  • Unlike expedite requests, fixed delivery date items will not involve putting other work aside or exceeding the kanban limit.
  • If a fixed delivery date items gets behind and release on the desired date becomes less likely it may be promoted in class of service to an expedite request.

Standard: The Standard Class of Service is used for the typical work that goes through the system. The mechanisms of flow and focus will move the work through the system as fast as it can be done without disrupting the system. Large Standard Class of Service items may broken down into smaller items with each item queued and flowed separately. Standard Class of Service work should be pulled into each queue on a First in First Out basis. Estimating Standard Class of Service items beyond T-shirt sizing doesn’t add any value (although even t-shirt sizing could be argued is not adding value) – if it is work you are going to do then you should go ahead and do it.

Sample Standard Class of Service Policy:

  • Standard class items will use yellow colored cards.
  • Standard class items will be prioritized into the input queue based on their cost of delay or business value.
  • Standard class items will use First in, First out (FIFO) queuing approach to prioritize their pull through the system.
  • No estimation will be performed to determine a level of effort.

Intangible: The Intangible Class of Service is used for work that goes through the system that doesn’t directly deliver value to the customer. These are items like production bug fixes, retiring technical debt, usability improvements,or branding  and design changes. This is work that needs to be done – but for which it is hard to show an ROI. It is a good idea to have some Intangible work going through the system. It is better to set this aside when an Expedite comes through then work with an associated due date or cycle time expectation. I like to set a policy that at least one intangible item is moving through the system. Again, the Intangible Class of Service items may be broken down into smaller items with each item queued and flowed separately.

Sample Intangible Class of Service Policy:

  • Intangible class items will use green colored cards.
  • Intangible class items will be prioritized into the input queue based on their intangible business value.
  • Intangible class items will be pulled through the system regardless of its entry date so long as a higher class item is not available as a preference.
  • No estimation will be performed to determine a level of effort or flow time.

Why Do We Care About Classes of Service

Not all work has the same value as it moves through the system. Additionally, there are varying levels of time pressure on the items moving through the system. Planning and Coordinating all the possible impacts would be very difficult. Classes of Service create a simple and transparent approach for the team to self-organize around the work to meet the needs of the business. As each performer is looking to pull their next item into their queue, they scan the candidate items. In the sample above, they would first pull an Expedite if one existed. If not, and there was a Fixed Delivery Date item that needs to be started soon to meet the Fixed Date then they would pull that. If that doesn’t exist they could either pull a Standard Class of Service item or, if there aren’t any intangible class of service items active on the board, they would pull an intangible on the board.

Using Classes of Service to prioritize pulling and swarming results in an easy to sustain system that self levels risk and value optimization. It inspires flow behavior, empowers the team, increases employee engagement and optimizes the value produced by the system. Classes of Service also create transparency into the promises made to the customers and increases the reliability of promises being kept resulting in higher trust across the organization. So, we care about Classes of Service because, for a minimal investment, they increase value, balance risk, improve reliability, increase employee engagement and increase trust within the organization.

Tags: , , ,

6 Responses to “Kanban: What are Classes of Service and Why Should You Care?”

  1. Work In Process (WIP) Limits, Policies, Etc. - new ThoughtStream("Derick Bailey"); - Los Techies : Blogs about software and anything tech! says on :

    [...] get the feeling that we will eventually be using many different of Classes of Service… but this is a great place for us to [...]

  2. Markus Andrezak says on :

    These last two posts are just brilliant! Thanks!


  3. Markus Andrezak says on :

    Just comes to my mind, as we just suffer from expedites that are too large: It is of course crucial to try to elminate the (organizational?) root causes of too many surprising expedites from my PoV


  4. Does A Kanban System Eschew Estimation | AvailAgility says on :

    [...] Dennis Stevens has recently written some great posts discussing knowing when we will be done, using classes of service and service level agreements to manage [...]

  5. Agile is a Service: You May Be Improving the Wrong Things | Agile CMMI blog says on :

    [...] service to the customer.  Kanban (more recently) even refers to different types of work as “classes of service”.  In fact, if we look at the most common pains in development work (e.g., staffing, time, [...]

  6. Alternative Kanban Board Design says on :

    [...] knows how to cope with each task. What is the role of columns then? Priorities! The old idea of classes of service. The closer the task is to the right side of the board the more important, or urgent, it is to deal [...]

Leave a Reply