The Benefits of Defining Your Service Level Expectation

“In Kanban, how do you determine what size of work item you should pull in?”

This was recently asked in one of my Kanban classes.

Often, this type of question comes from someone familiar with the Scrum framework who is trying to understand how to break work items down in Kanban. As part of the Definition of Workflow, the Service Level Expectation (SLE) is instrumental in helping the team determine the size of work. Let’s break it down to understand how.

Introducing the Service Level Expectation (SLE)

The Service Level Expectation, otherwise known as the SLE is the timebox of Kanban. It is a forecast of the elapsed time it will take a single item from started to finished, based on the team’s past work.

The SLE has two parts, a period of elapsed time and a probability for that time. For example: 85% of work items will be completed in 10 days or less.

By stating a range, “10 days or less”, we are acknowledging work may take less time. Giving a confidence level of 85% indicates the chance it could also take longer.

The team can use the Service Level Expectation to determine if work is small enough to pull into progress. The SLE also helps the team to manage work in progress and towards improving the workflow. It even gives the team a language to communicate when work will be done. Yes, the SLE is that versatile.

How to determine the SLE

If the team has been working together, the SLE is based on work the team has previously completed. In the example of the Cycle Time Scatterplot below, you can see the SLE represented by the horizontal dotted lines.

The Cycle Time Scatterplot provides the amount of elapsed time between when a work item started and when a work item finished. Work items are plotted to this chart based on the number of days the item was in progress and the date the work item was finished.

Based on the image below, the team for the chart below will complete 85% of work items within 16 days or less.

If past data is not available as in the case for new teams or teams who are new to managing their work, ask the team for their best guess. Once the team begins collecting data, update the forecast.

Calculating the probability percentiles yourself

It is important to note that the percentiles are not averages and you don’t need to understand statistics for it. If the tool you use does not offer percentile lines, you may calculate by taking the total number of work items done within a given period of time, multiplying it by the desired percentile and then identify where that count falls within the data.

For instance the team in the previous scatterplot example completed 19 items in the period of time shown. To get the 85th percentile, multiply 19 by 85% (0.85).

19 X 0.85 = 16.15

The 85 percentile line is at 16 days and there are 16 items at or below that percentile line. The other three items exceeded the 16 days.

This gives us a 85% probability to complete an item in 16 days or less.

Now that we know what it is, how does it help us?

Break work down to the smallest level of value

Work does not need to be the same size for this to work. It is realistic to say a team will have work of different sizes. Development teams may work on stories and defects that take a different amount of time. Services or Operations teams may receive different types of requests, for example some that take less than a day, others that take three to five days, and still more that are exceedingly complex.

Work items on a Kanban board should be split to the smallest level of value. Small items of value help work flow through the system, have greater potential for reducing work not needed, allow the team to pivot quickly when needed, and provide an opportunity for frequent feedback.

For those of you familiar with Scrum, you may be familiar with identifying a piece of work a team will pull into a Sprint as small enough to be completed within the sprint. The Sprint is the timebox in Scrum. The same rule applies in Kanban with the SLE. Before pulling a work item into progress, the team should agree that the work for that item can be done within the team’s SLE.

Managing Work Item Age

The most powerful use of the SLE is to help a team manage the age of work items in their system.

By knowing the SLE as a timebox for work, the team is able to have dialogue in their Daily Scrum or Standup of the aging of work items on the board. Work item age should be managed daily. The team should discuss any items nearing or aging past the team’s SLE.

Common examples of work aging past the SLE may include blocked work, interruptions, or discovering the work is more complex than the team expected.

Work that is getting older on the board should be discussed by the team. The team may decide to swarm together to get the item finished. The team may also find the work was not divided down enough and may be able split the work further to allow feedback on what is ready to be finished.

The example below is of an Aging Work in Progress chart. The percentile lines of the chart show a visual to the team of which items are aging older on their Kanban board. The Aging Work in Progress chart is a current state representation of the team’s Kanban board.

If the Aging Work in Progress chart is not available in your tool, the team may use the SLE to manage aging from the Kanban board by using visual cues to indicate the work item age on the work items represented on board.

Managing Expectations

The SLE gives an answer to the question everyone wants to know: “When will it be done”? This is for single items only. If you have a batch of work, the SLE is not the appropriate tool.

While teams are often reluctant to put a number on how long things take to flow through their system, there is value in having a level of confidence in elapsed time that is backed by data.

Because complex work has too many unknowns to be 100% certain of an end date, the SLE forecasts a range. This is communicated as the item will be completed in X days or less with X% confidence. Through this, the team acknowledges there is a level of risk in meeting that time frame and is able to manage the expectations of the customer.

The higher percentage of confidence the customer wants will result in communication of a longer forecast of time to offset the lower tolerance of risk.

The key is to maintain communicating it as a range and level of confidence so as not to create confusion toward a guarantee.

‍