Skip to main content

Forecasting with Kanban : Why “Service Level Expectation” is the better term

Last post 02:13 pm May 21, 2021 by Peder Bjerre Nielsen
No replies yet
02:13 pm May 21, 2021

I personally prefer “Service Level Expectation” (SLE) over “Service Level Agreement” (SLA) (SLE is also the term used in the The Kanban Guide for Scrum Teams). I find that the very term SLA dangerously paves the way for focusing on fixed contracts at the expense of customer collaboration which is precisely the opposite of Agile (cf. The Agile Manifesto).

 

To me there is more realism and authenticity to the term SLE.

 

Knowledge work is, to say the least, not very predictable. However it does not imply that we can not set any expectations. Forecasts are still relevant or possible. They should however include a probability.

 

This is where Kanban and Scrum are ideally combined. 

 

Using Cumulative Flow Diagrams (CFDs) is a great way to determine whether we have a stable system. Using CFDs we can measure if the rate at which work items flow into the system (arrivals) is the same as the rate at which work items flow out of the system (departures). When we balance arrivals and departures we are on a way towards process stability. Presupposing that we have a stable system then using Cycle Time Scatterplots and thereby visualizing Cycle Time data we can start making reliable forecasts about the completion of specific work items. By adding percentile lines to our Scatterplots we get a clear overview of our Cycle Time data. The 50th, 85th and 95th are some good standard percentiles. 

If, for example, our Cycle Time Scatterplot Diagram shows that the 50th percentile for the Cycle Times is 12 days, the 85th percentile for the Cycle Times is 26 days, and the 95th percentile for the Cycle Times is 46 days, we can make a reliable forecast. While taking into account the confidence level with which the customer is most comfortable, we are now able to answer the million-dollar question: 

 

“When will it be done?”

 

The answers to the question could be:

 

“There is a 50% chance that it will be done in 12 days”, or

“There is a 85% chance that it will be done in 26 days”, or

“There is a 95% chance that it will be done in 46 days”.

 

These are all SLEs. A proper SLE should always include both a probability and a range. The SLE depends on the desired confidence level of the customer. This type of probabilistic forecasting is compatible with the uncertainties of knowledge work. It is a good way to establish a mutual understanding between the team and the customer. As such it serves as a good basis for future customer collaboration. Thus using Kanban within the Scrum framework can very well contribute to the practice of close customer collaboration.

During Sprint Planning when the team selects work for the upcoming sprint the SLE can be used as a measurement for right-sizing the work items. The team quite simply asks the question if a certain work item can be completed within 12 days (or 26 days). If the answer is yes the item can be selected for the upcoming Sprint. If not, the team might want to do some more product backlog refinement to see if they can break up the item.

 

The above-suggested answers are all expectations, not fixed agreements.

 

As I stated in the beginning I personally prefer “Service Level Expectation” (SLE) over “Service Level Agreement” (SLA). “Agreement” reminds me too much of a fixed contract and as such could lead to endless discussions between the team and the customer over conformance issues. Considering that the sole purpose of a Scrum team is to create value such activities are wasteful.

 

Therefore I prefer SLE over SLA. 



(I can recommend “Actionable Agile Metrics for Predictability: An Introduction” by Daniel S. Vacanti as it explains how to visualize data such as Cycle Time in analytics like Cumulative Flow Diagrams and Scatterplots)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.