A Service Delivery Review should help people decide how to improve a service. It is not a presentation of every chart and it is not a status meeting in which each person explains their work. The review compares customer expectations with actual delivery capability, investigates meaningful variation, and ends with changes to policies, experiments, or escalation.
Kanban University describes cadences as feedback loops that support evolutionary change. Its official explanation of Kanban cadences also makes an important practical point: teams do not need seven new meetings. Existing meetings can be adapted or combined when the purpose, evidence, and decision rights remain clear.
What the review must answer
- Is the service meeting the expectations of the customers it is designed to serve?
- Where is work waiting, ageing, being blocked, or arriving faster than it can finish?
- Which work-item types or service classes behave differently enough to need separate policies?
- What changed since the last review, and did the previous experiment improve the result?
- Which decision can this group make now, and which issue needs another cadence or authority?
Prepare a one-page evidence pack
Use the smallest set of evidence that can change a decision. Show distributions and trends instead of one attractive average. Segment the data when different work types follow different paths; combining urgent production incidents with ordinary requests can hide the behaviour of both.
| Evidence | Question | Common misuse |
|---|---|---|
| Customer expectation | What does fit-for-purpose delivery mean for this service? | Assuming every customer values the same speed or predictability |
| Lead or flow time distribution | How long does comparable work take? | Reporting only the average and hiding the tail |
| Throughput | How much comparable work finishes over time? | Treating volume as value or comparing unlike teams |
| Ageing WIP | Which active items are becoming unusually old? | Waiting until an item is formally blocked |
| Blockers and failure demand | What repeatedly interrupts or sends work back? | Listing incidents without identifying patterns |
| Previous actions | Did the policy change produce the expected effect? | Starting a new experiment before reviewing the old one |
A 60-minute agenda
- Restate the service, customers, and review period in five minutes. Clarify which decisions are in scope.
- Review customer outcomes and expectations for ten minutes. Start with service fitness, not internal activity.
- Inspect flow, ageing, blockers, and demand patterns for fifteen minutes. Ask where the distribution changed and why.
- Review previous experiments for ten minutes. Continue, adapt, or stop each one based on evidence.
- Choose at most two new actions for fifteen minutes. Name the policy, owner, expected signal, and review date.
- Confirm escalations and publish the decision record in five minutes.
Use hypotheses, not vague actions
Replace ‘improve handoffs’ with a testable statement: ‘If security review begins when an item enters implementation instead of after development, the age of security-blocked items should fall during the next four weeks without increasing rework.’ The statement identifies a policy change, an observable signal, a time window, and a balancing concern.
Decision record template
| Field | Example |
|---|---|
| Observed condition | Items requiring external review form most of the oldest WIP |
| Current evidence | Ageing distribution, blocker reasons, and two recent item histories |
| Decision | Introduce an earlier review trigger for this work-item type |
| Expected signal | Fewer items crossing the agreed ageing threshold |
| Guardrail | No increase in abandoned reviews or reviewer overload |
| Owner and review | Service delivery manager; review in four weeks |
What not to do
- Do not compare teams through raw throughput when item definitions and systems differ.
- Do not make every outlier a performance problem; inspect the work type and system conditions first.
- Do not let the review become a queue of individual status updates.
- Do not leave actions without an owner, expected evidence, or review date.
- Do not add meetings when an existing review can carry the feedback loop effectively.
Where this fits in Kanban Systems Improvement
Kanban University lists running cadences, using metrics, managing delays and variability, and improving connected systems among the outcomes of Kanban Systems Improvement. The KSI course and KMP guide explains the broader learning path, while the Kanban Method guide provides the system-design context behind this review.
If your team has not yet defined work-item types, explicit policies, service classes, or a meaningful flow boundary, start with Kanban System Design training. If the system exists and the challenge is managing feedback, delay, variability, and connected services, review the Kanban Systems Improvement training.
