Classes of service is a mysterious concept in Kanban. The name itself might be confusing. Class of services? Classes of services? What does it mean, after all? Even more confusing is the practical application and, most importantly, why you would need them in the first place. While the implementation of сlasses of service is pretty straightforward, understanding the logical basis of the technique might be a bit trickier. As a matter of fact, in many occasions you won’t need them at all. We’ll explore this idea in the article, but before we do this, let’s start with a short story.
In a Bank
It begins in front of a bank office on the eve of a big public holiday when hordes of people roam the city trying to make their last preparations for the celebration. Unfortunately, on that very day I have to withdraw some cash from my business bank account.
I enter the bank. Although I know exactly what to expect, I’m still bewildered by the picture before my eyes. The bank is crammed. The lines are five times bigger than on an ordinary day. But I have no choice, so I go straight to my personal bank assistant to sign some papers. She redirects me to the bank teller where I will request the withdrawal. She asks me to get a ticket from the ticketing system — a simple kanban card. So far so good.
Then something strange happens. The next step is another teller that dispenses cash, but before redirecting me there, this teller takes my ticket from me. The ticket which reads ‘A’ and is the usual ticket for this kind of service. The teller gives me a new ticket instead. The new one has ‘B’ on it. Not really understanding what’s happening nor paying too much attention to it, I go back to the waiting line. The line is huge and intimidating. I brace myself and prepare to spend there at least an hour. The time starts ticking.
It is then when I notice, that there’s something specific about the waiting line. There’s a lot of people in the hall, all of them holding the ‘A’ tickets. Oddly enough, none of them has a ‘B’ ticket. None, except for me. I have my own queue in which I am the only person and my turn comes immediately. I haven’t waited even for a couple of minutes. Then it dawns on me. I’ve just experienced a privileged class of service.
Applying Classes of Service in a System
You might be asking yourself now, what exactly had happened in the bank? Let’s take a closer look.
First of all, a bank is a queueing system. Any queueing system has such characteristics, among others, as customer arrival rate and customer waiting time. The relation between these two parameters is defined by the very simple and equally powerful Little’s Law. What happens if the queues are large? Little’s Law has a definitive answer: waiting time grows proportionally. This is quite intuitive and this is what we observe in the story. The the main contributors to the situation are regular customers (the ‘A’-ticket type), but it affects everybody in the bank including the business clients (the ‘B’-ticket type).
However, from the bank’s perspective the situation is less than perfect. The bank doesn’t treat all its customers equally. Regular clients are sporadic. Their behavior depends much more on the bank’s location than on anything else. The loyalty of business clients, in contrast, is closely tied to the quality of service they receive. The bank doesn’t want precious business clients to suffer from poor service, even on public holidays. In order to mitigate the situation, they implement a very logical thing.
Usually the ticketing system in the bank directs all customers to a single queue. A customer takes a ticket with a number and waits until the number appears on the screen, then goes to whichever teller is free at this moment.
This time the bank does something different. It introduces two classes of service — the privileged Business class and the Regular class, which is everybody else. It allows to redirect all business customers to a dedicated queue served by dedicated tellers. The new dedicated queue is much shorter than the combined. And as we know from Little’s Law, it means decreased waiting time for all business customers. In other words, the business clients start receiving service of a privileged class. Another typical place where privileged classes of service are common is airports. There you can see Economy and Priority boarding lines and customers pay a premium to get into the latter.
In a bank, to make the privilege work, business customers are provided with excessive server capacity. Simply put, they are served by more tellers. Which means that regular customers will suffer from longer waiting times, but the bank is ready to tolerate that.
However, does a new class of service always bring significant benefits? Let’s examine this question in a few simple simulations.
Mechanics of Classes of Service
Mathematically speaking, we’ll be looking at the M/M/c queue model. In all our examples we will assume service rate, i.e. how many customers one teller serves per unit of time, to be
- service rate, customers per hour: μ = 15.
The simulation will run for 200 arbitrary customer somewhere in the middle of a typical work day. There’s nothing special about these numbers. All simulation parameters in this article are chosen in such a way as to provide better demonstration of various possible cases. If you want to play with the simulation yourself, the seed I used was 35, initial deletion ratio 0.7.
Let’s say, a bank starts with a single queue with no distinction between Business and Regular. For simplicity and to make it more illustrative, let’s assume:
- total arrival rate, customers per hour: λ = 70;
- number of tellers: c = 5.
As you can see, the expected (i.e. mathematically calculated) average waiting time (i.e. average queue time plus average service time) for a customer is 14 minutes. The observed waiting time is 9.3 minutes. This number will get closer to the expected value as we run the simulation for more customers. Now the bank wants to improve the service for its Business customers and creates a new privileged class of service. Two tellers are dedicated to serve solely the business clients. Let’s see what happens:
- let’s assume business customer arrival rate, customers per hour: λ = 10;
- number of tellers: c = 2.
Just by redirecting business customers to a separate queue the bank is able to improve expected waiting time almost threefold and observed waiting time almost twofold. Now, let’s take a look at what happens with the Regular customers:
- regular customer arrival rate, customers per hour: λ = 70 – 10 = 60;
- number of tellers: c = 5 – 2 = 3.
The queue grows to infinity, as does waiting time. Of course, in real life there’s no infinity. The bank either waits until the arrival rate drops and the system stabilizes or locks the door and denies service for any new customers. In both cases waiting time for the customers in the queue is huge and stays huge until either of the two events above happen.
An important conclusion we can draw from these three figures is that whenever there’s a privileged class of service that provides benefits to a certain type of customers, waiting time for everybody else increases. In other words, some people get their privilege at the expense of others.
But make no mistake. We’ve seen only one case from many possible. Let’s run the simulation with some different parameters.
For a system with a single queue:
- total arrival rate, customers per hour: λ = 50;
- number of tellers: c = 5.
The expected waiting time is 4.8 minutes, the observed waiting time is 6.2 minutes.
For business customers only (the parameters and consequently the results are the same as above):
- business customers arrival rate, customers per hour: λ = 10 (same as above);
- number of tellers: c = 2.
For regular customers only:
- regular customer arrival rate, customers per hour: λ = 50–10 = 40;
- number of tellers: c = 5–2 = 3.
The expected waiting time is 14 minutes, the observed waiting time is 13 minutes.
In this example the improvement for Business customers was insignificant, but it made the life of Regular customers much worse. Sometimes the game is just not worth the candle.
In software development the behavior of the queueing system might be a lot more complex. Practically it would be very hard to find the optimal conditions for having multiple classes of service. For instance, unlike tellers in a bank, it’s almost impossible to predict the change in service time if you change capacity allocation on different types of work. The only thing you can do is look back at the historical data and guess. That’s why the crucial part of Kanban is experimentation and empiricism. You and your team will have to make a decision whether you need a new class of service based on your own context and then put it to trial.
The Biggest Truth about Classes of Service
Finally, after thorough examination of all the examples, I can formulate the biggest truth about classes of services. I can summarize it in five points:
- Classes of service intend to achieve a specific business goal. This is done by introducing a specific way of servicing customers.
- Classes of services are differentiated either based on the type of customers or on the type of work that impacts the customers in a certain manner.
- Introducing a privileged class of service for one type of customers or work always occurs at the expense of the other types of customers or work.
- Adding a class of service is not always economically reasonable, as the unprivileged class may suffer unpropotional losses compared to the benefits that the privileged class gets.
- Corollary to 1, 2, 3, and 4, when you think you need a new class of service, think again. The drawbacks may easily outweigh the benefits.
A good example is the Expedite class. By design, Expedite work items must be processed with top priority and can bypass the entire queue. This happens at the expense of all other types of work and makes other classes less predictable. The effect of this might be quite unexpected. Reduced predictability of regular classes of service sends an unequivocal message that the only way to get things done here is to expedite. This leads to abusing the practice and makes other classes of service even less predictable. The system enters a vicious cycle. That’s why teams usually have very strict rules of how many Expedite items can be in the system or how often they can be added.
And it has the same effect on less obvious kanban setups. Prioritizing bugs over features? Features will be delayed as long as there are bugs in the system. Putting deadline items in front of regular items? Your most valuable customers will be happy, but the combined frustration of everybody else may outweigh their voices. Sacrificing technical improvements for faster delivery? End users will get the desired features quicker, but innovation will suffer and the product’s internal quality will decay rapidly.
Conclusion
Classes of service is a powerful tool that can be used for achieving specific business goals. A privilege created by a class of service happens at the expense of other classes. Use classes of service when there’s the need to provide your customers or your business with specific benefits. This includes benefits with direct (features) or indirect (improvements) impact. Don’t use classes of service if there’s no business goal to drive them.But even when there is one, make sure if the new classes of service actually help rather then hurt.