To set a service level expectation (SLE) for a Kanban team in Azure DevOps, read the cycle time percentiles of the work your team has finished and state the target as a number of days plus a probability, such as "85% of our items finish within 10 days of starting." Then compare each in-flight item to that number every day, and review the items that missed it, worst first, so work that is stuck too long gets attention while you can still act.
Get Done right first
An SLE is a promise about when work reaches a finish line, so the line has to be where your team means it. In Agile Analytics, Done is the first state mapped as Done in Workflow Mapping (Tools, Configuration, Workflow Mapping). If Ready to Release is mapped as Done, the clock stops there, and time after it is not cycle time. Decide what your SLE promises before you read any numbers. "Ready to release" and "in production" are different promises, and the mapping should match the one you make. The Workflow Mapping guide walks through checking each state.
Pick the SLE from your own cycle time percentiles
Open Cycle Time in the Plan group. It shows a scatterplot of completed items with p50, p70, p85 and p95 percentile lines, plus a histogram view of the same items. 85% of the items finished at or under the p85 line.
- p50 is a coin flip: half your items take longer. It describes the typical item but is too weak to promise.
- p70 suits a team that wants an ambitious target and accepts more misses.
- p85 is a common starting point. It covers most work without being pulled out by the slowest few items.
- p95 fits work where a miss is expensive, but it usually sits far out in the tail and makes a loose promise.
Use history that matches how you work now
If the board, the team or the Definition of Done changed recently, older items describe a different system. If bugs and stories behave very differently, one SLE may fit neither, and two may be more honest. The controls of the view are covered in how to measure cycle time in Azure DevOps.
State it as days plus a probability
Write the SLE as one sentence with both parts. An example, not a benchmark: "85% of our items finish within 12 days of starting." A number of days on its own reads like a deadline for every item. A probability without days says nothing. Together they tell a stakeholder what to expect when an item starts, and remind the team that some items will miss by design. Say what starting and finishing mean on your board, so nobody argues about the clock later, and revisit the number on a fixed rhythm, such as once a quarter, rather than after one bad week.
Watch in-flight items against it
An SLE is most useful before an item finishes. Aging & Blocked, in the Health group, plots every in-flight item by its days in flow against the team's p50 and p85, ranks items by urgency, shows blocked items, and keeps the state lanes in your board order. This is the answer to "how do I find work items stuck too long?"
- An item past the p50 line is older than half of your finished work. That is the moment to ask what it needs.
- An item already older than your SLE will miss it whatever happens next. Swarm on it or split it.
- If you picked p85, the chart's p85 line is a close guide, but it moves as new items finish while your SLE stays fixed. Keep your number in view.
Reopened work
Reopened items are aged by the days actually worked, so a reopened item does not jump to the top just because it was first started long ago. To make aging part of the daily conversation, see using aging work items to run better standups.
Review misses worst first
Some items will still miss. SLE Violations, also in the Health group, shows service level expectation compliance per target and a worst-first list of completed items that missed the window. Use the list in a retrospective. Start at the top and ask the same question for each item: where did the time go? Look for patterns such as waiting for review, an outside dependency, an item too big to start, or work that sat in a queue. One slow item is a story; five with the same cause point to a process change. Keep the review about the system, not about who held the item.
- Compliance well below your stated probability means the process has a problem, or the SLE came from an unusual period.
- Compliance well above it for several months means you can tighten the SLE.
Try it
Agile Analytics runs on Azure DevOps Services (cloud). The 30-day free trial starts on install with no credit card, and everyone in the organisation has full access while it runs. The cycle time analytics page shows the charts, and the extension is on the Azure DevOps Marketplace.
Related: Cycle time analytics for Azure DevOps · Install instructions