Service Level Expectations in Scrum with Kanban

As work ages without completing, it becomes more and more likely this work item would not meet the team’s SLE. For example, once a work item reaches a point where it’s age is now at the point where half of the team’s work items have already completed, it’s a clear indication that there’s more risk for this item than the typical item.

We basically learn about the increased risk to specific items the more time passes without them completing. Common sense, no? The idea is that by visualizing these items and that growing risk we can focus the team’s tactical inspection and adaptation during the Daily Scrum on tackling these risky items.

Let’s look at an example. Let’s assume that indeed we have a Development Team that learns from their cycle time scatterplot that 85% of their work items finish in 8 days or less and 50% of the items actually finish within 4 days. They have an item A that has been active for 5 days already and an item B that has been active for 3 days.

Which of these items should the team feel more confident they can finish within their 8 days or less SLE? Without further information about where each of the items is in their workflow, they should feel more confident about item B that aged less. Item A has already been active more than it takes for 50% of the cards to finish, so it’s quite a strong signal that there’s a flow risk to it. Basically, with each day that passes in which a work item doesn’t finish, the probability that a work item will not meet its SLE increases”.

Beyond its usefulness for in-Sprint flow focus, SLEs are also useful during Sprint Retrospectives. The “surprise” or “anomaly” of missing your SLE can drive an improvement discussion. I previously wrote about the Sprint Forecast as an expectation and the learning/improvement value of having an expectation that you miss vs having no expectations.

This “no expectations” problem is actually a common concern for Scrum practitioners when they look at Kanban. The Sprint Forecast/Commitment provides that expectation. Kanban without SLEs indeed is missing something. Having WIP limits as expectations improves flow but doesn’t help with specific items that aren’t flowing well.

How should a Scrum Team come up with their SLE? First of all — The SLE relates to the Development Team. They should figure out what their SLE should be. If possible based on historical cycle times. If there isn’t enough data, make a best guess and replace it with empirical data-based information as soon as possible. If it isn’t based on historical cycle times, you cannot really expect to make any educated confidence-level determinations (like the one above) based on your SLE.

Also, SLE’s aren’t SLA (Service Level Agreements). SLA is a loaded term that means different things in different contexts but generally is an external commitment about the service levels a team will provide. As mentioned an SLE is mainly internally focused.

SLEs are used by Scrum Teams to set flow expectations to themselves. SLEs are ideally created based on actual historical cycle time data. They are then used by teams to focus their flow inspection and adaptation effort — during the Sprint in the Daily Scrum and following the sprint in the Sprint Retrospective. They can also used in the Sprint Review when the team is working with stakeholders that care about the team’s cycle time.

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.