Are you trying to deliver a key strategic project? Are you constantly interrupted by support or business as usual (BAU) type activity?
In Kanban, Classes of Service provide a transparent mechanism for capacity management. They control the balance of different work types delivered. A common use for classes of service is to strike a healthy balance between unplanned (BAU) work and planned work. It’s important to track the balance of work delivered each week to provide feedback into the selection policy used for the Next column. Implementing classes of service provides real transparency to help with stakeholder conversations and expectation management.
Classes of Service in action
Getting started with classes of service
Classes of service are a set of work in progress (WIP) limits across the WIP areas of your Kanban system. It’s a method of ringfencing capacity for certain work types instead of ringfencing resources. It provides a mechanism to change the balance of work across the team.
How Classes of Service work
Visualise the classes of service using colour coded index cards within the Kanban system. Calculate the total capacity of the system by adding up the WIP limits of each column. Allocate each class of service a percentage of the total system capacity and translate this into number of cards per class.
In the illustration above, the following capacity rules apply:
- 3 yellow cards can be in progress
- 1 pink card can be in progress
- 1 blue card can be in progress
- In progress means, either in WIP or SIGN OFF columns.
To start a new yellow card, complete an existing one first.
Striking the balance
Getting the balance right on work types is important. For example, prioritising new shiny features over servicing tech debt is great for revenue, but bad for long term cost and supportability. To protect against one work type dominating all others, track the data and publish accordingly. It’s important to keep a track of types of work items delivered each week. Plot this data in a stacked bar chart as follows,
Track the number of each work item type over time. This provides a number of ‘dials’ to influence the selection policy for the NEXT column. The limits you set for each work type are the dials.
Using Classes of Service to service Technical Debt
Not servicing Technical Debt frustrates developers. The servicing of Technical debt is often second place to creating shiny new features. Some organisations set a rule that 10% of every team’s capacity must be used to service Technical Debt.
Classes of service are extremely powerful for teams who experience a mix of planned and unplanned work. They are easy to set up, and provide an additional dimension for selection decisions in your Next column. They provide real insights into how your prioritisation and selection policies are working within your organisation.