SLAs and WIP limits: Which One Do You Need?

A few days ago, our marketing team had its weekly replenishment meeting, and somehow we started a discussion around the following topic:

Do we need both WIP limits and service level of agreements (SLAs)?

Well, the short answer is yes.

But the answer can also be "it depends."

So, it depends on what?

After a while, we came up with 3 scenarios. Let's see them. And please don't judge us hard. After all, Kanban is about continuous improvement.

If you are not familiar with SLAs and WIP limits, we will discuss them further in the article, so stay with us.

Scenario #1 SLA's Only

This is a bit tricky, but let's try.

First of all, let's briefly discuss what a service level agreement (SLA) is. In Kanban, a service level agreement (SLA) is an agreement on a cycle time target. The other aspect that shapes SLA is the level of certainty that this cycle time can be met. For those of you that are not familiar with Kanban, it may sound complicated, but it is not.

Simply said, if the historical flow data shows that 90% of a number of tasks are completed within 4 days, then we can agree that each of those tasks can be done in 4 days in the future with a probability of 90%. In other words, we can agree that our SLA is 4 days. In software engineering, SLAs are oftentimes defined in the form of software development agreement contracts.

Second, different classes of service in Kanban may have different SLAs. It depends on the nature of tasks. For example, expedite tasks will definitely have shorter SLA, than standard tasks. Our team has an SLA of 1 day for expedite tasks and 4 days for writing content (I hope I will meet this one). Again, this may vary from team to team and from company to company, so let's not make it more complicated.

Where were we? Oh yeah, what if we have only SLA?

Let's imagine that you only use SLAs and you don't limit work-in-progress. Hypothetically, you know that each task should be finished within the agreed SLA. However, if nothing alarms you that you are doing too many things simultaneously, which is the role of the WIP limits, your team may end up working on a bunch of tasks. In other words, your team members will try to multitask - something that practically doesn't exist and multiplies the cycle time of tasks.

Multitasking is nothing more than context-switching that occurs in the brain. When you think you are multitasking, your brain actually stops working on the current task and focuses on the other. It is pure biology - the brain is not capable of intently concentrating on two serious tasks at the same time. This makes it more difficult to organize thoughts and filter out irrelevant information, thus increasing cycle time and reducing the quality of the entire work process.

So, we know that SLAs are good, but we need WIP limits and WIP limits only.

Scenario #2 WIP Limits Only

This one should be easy, because what is Kanban without WIP limits? It is like Tesla without the battery, isn't it? If you didn't laugh here I won't blame you.

If you are not a nerd like me and you are new to the concept of WIP limits, in short, work-in-progress limits restrict the maximum amount of work items that can be underway in the different stages (kanban board columns) of the workflow.
To make it a bit more clear, let me show you the WIP Limits in action:

Anyway, applying WIP limits in the different stages of the workflow will help you optimize work capacity by allowing you to pull new work only if capacity is available. Which is great because it will help people focus on finishing work.

There is always "BUT".

But, what if you hold tasks in progress much longer than needed? Tasks will start pilling up in the backlog or requested area.

Now, imagine this: you have set WIP limits on every stage of your workflow, and it works great. The team is focused on finishing tasks, the workflow is smooth. However, you suddenly realize that you have tons of tasks waiting to be started.

Why is that? Why are tasks not moving faster? You check the average cycle time, and it turns out it is huge. So while your team was calmly working on its tasks, new work items were gradually pilling up.

Well, this is probably because you didn't have a service-level agreement.

And this is how we came up to the conclusion that you have to use both.

Just to clarify, situations may vary from team to team. Maybe only 3 of your teammates are working slower, not the whole team. This is just an example.

Scenario #3 WIP Limits and SLAs

As it becomes clear from everything that you have read until now, if you:

1. Apply only SLAs, and you may start so many tasks simultaneously that you will end up jumping between them, losing productivity and generating enormous cycle time.
2. Apply only WIP limits, and you may lose track of time and generate an enormous queue of waiting tasks to be started.

In both cases, your overall performance will suffer.

This is why we advise you to use both WIP limits and SLAs. I don't say it is a must, but if you want to be precise it is a good idea to use a software solution that tracks and records historical data about your workflow. It is just more convenient.

In this line of thought, when you have data about the average cycle time, you may set standards that will help you improve work processes. One of the tools you can use for such purposes is the cycle time histogram. For example, it can notify that 85% of the work items (for a certain period) are completed in 6 days or less, so you may set your SLA at 6 days. From this point, you can start improving. After a month, you can check it again and it may turn that the SLA can be decreased to 5 or 4 days.

On the other hand, setting WIP limits will help your team focus on finishing current tasks and optimize capacity.

At the end of the day, applying WIP limits and SLAs will help you decrease the average cycle time and react much faster to internal and external requests. This is how it works for us. But as I said earlier, different teams work in different situations. If you think it won't work for your team, you can ignore it. But at least give it a try.

One last clarification, different classes of service may also have different SLAs. This means that you can have several SLAs within one team. But let's stop here and not get it more complicated.

I hope you are not bored to death after this article, and the topic has become a bit more clear now. Let us know your thoughts in the comment section below.