The Secret Weapon of Kanban: Classes of service
Ever heard of Kanban?.
Oh, you mean like Scrum, but without sprints?
Yeah, that’s not it.
Kanban is either completely misunderstood, or known to be a bit difficult, as it “has no rules”. Instead of rules, Kanban has values and principles that guides you towards a deep Kanban implementation. Practices like visualizing and managing flow, and making policies explicit are also important. Perhaps we ought to dive deeper into that, but not today.
This post is about one specific element of Kanban, Classes of Service.
Classes of Service is an element missing from many shallow implementations of Kanban. That is a shame, because it’s immensly powerful. Done right, Classes of Service will allow effortless prioritization, sequencing and balancing of work. It’s almost magic.
Let’s try to explain what it is, and how it works. A class of service is a policy defining how a team treats a specific type of work. You are free to define your own, but the following is the “standard” Classes of Service as presented by David Anderson. Rough explanation given in paranthesis:
- Expedite (Critical, selected before anything else, breaking WIP limits allowed)
- Fixed date (Full cost of delay in effect on or after a specific date, prioritize early enough to have high confidence of delivering before deadline)
- Standard (First In, First Out prioritization, items are picked roughly in the order they arrive. The majority of work should be in this category)
- Intangible (Cost of delay is low or non-existant in the short term. Pick when no Fixed date or Expedite is in queue. Example: Maintenance work)
I rarely deploy the “Intangible” class, because most teams I work with are so far behind they won’t have capacity to work with this class in the forseeable future. Instead I often introduce another:
- Urgent (Change request with a small (<1 week) and well-known solution, that we’d like to expedite before larger items of the Fixed Date or Standard Class of Service. Breaking WIP Limit not allowed)
The Urgent class is useful for teams that struggle with decomposing and decoupling work. They can use the Urgent class for small requests (changing a text on a webpage, non-critical but annoying bugs, etc). These would otherwise drown in the Standard class. When they achieve proper flow, this class may be removed, and Intangible introduced.
But how does this help exactly? Classes of Service replace the concept of Priority, which often has less meaningful definitions like Low, Medium, High or Pri 1, Pri 2, Pri 3. The introduction of Classes of Service and a reasonable WIP limit, means the team can sequence work automatically. Bye, bye endless backlog and/or sprint planning. Replacing priority with Class of Service also forces you to think about why something is important in a different and deeper way. Agreement on the Class of Service is also a powerful way to manage expectations.
Figure out what is most important right now, set the proper Class of Service (in collaboration with the team), and the team will sequence work accordingly. Ideally, the result is a team delivering a beautifully balanced and sustainable stream of work. If it’s still too slow, you need to reduce the amount of work in parallell.
This is the basics, you can achieve many fun things with Classes of Service when you really get the hang of it. In the mean time I hope this little introduction motivates you to try it out, and feel free to contact me if you have any questions or doubts!
