What are classes of service?
Classes of service divides tasks in different aspects. Every kind of work can be classified.
Some tasks get solved if you code a requirements, others will be solved by migrating data or exporting them into an specific format. Different kinds of work also have different priorities to each other. So, the classes of service span parallel flows over one Kanban board.
Each class of service can have its own WIP horizontal and vertical.
Therefore they also have different cycle times over the board.
Mostly used classes of service with their defined priority and succession are:
- Extremely Important
- Fixed delivery date or Timeline
- Standard Class or Feature
- Intangible Class or Chore
The extremely important class has the highest priority and it is not allowed to interrupt the workflow on this type of class. If a critical issue occurs, or a task must be solved just in time, you should use this kind of class.
The global WIP of an extremely important is only one. This class can break current tasks in progress and have precedence for all other tasks.
Fixed delivery date or Timeline
Features, which have a deadline, can have their own class and they have to be completed at a defined date. So they can have a parallel flow over other feature tasks, if necessary. Maximum 20% of all tickets in the current release can be a fixed delivery date.
Bugs are non billable tasks, which are the result of wrong solved customer requirements or programming issues. Bugs have to be corrected as soon as possible. In general, they have higher priority as features.
The bug class has no specific assignment in a release.
Standard Class or Feature
Represents the tasks to solve a customer requirement. A standard class is a normal task and will be treated by the FIFO (first in, first out) principle. This class has no timelines. Maximum 50% of all tickets in the current release can be standard class.
Intangible Class or Chore
Useful but negligible tasks have the class intangible class and they are not urgent tasks. This could be a task for an upgrade or support as a data optimization.
Also little UI improvements into backend UI’s or something that does not take value.
Intangible class will be pulled by void or need for clarification of other tasks. They can escalate to urgent tasks if not considered over longer time. Maximum 30% of all tickets in the current release can be a intangible class.
If a data optimization was not resolved, they could result in a critical performance issue.
Then the tasks will get an other service class. And, in worst case, an extremely important one.
Why we should use them
If all of the tickets have classes of service, the order to progress the tasks are found at a glance on the board. Extremely important tasks should be processed immediately. Fixed delivery date tickets have the second highest priority. Bug fixes if the current work is done. Features, Chores in the order they are placed into the backlog.
Also we have different cycle times, so we can measure how fast we solve critical issues or fix a bug. These information are necessary to improve the response time of a team and also train them to prioritise tasks on their own.
Problems with intangible classes
Intangible or chores are a problematic class.
Because of no direct value for them, customers sometimes do not really want the tasks or tickets of this class, at first sight. But the intangible class can escalate to critical issues if they are not solved.
So we should therefore prioritise them into the backlog and get them the same priority and swimlane as standard feature tasks. No feature tasks should break the progress on a intangible class, except the feature becomes an extremely important class.