Service Delivery Review

---

Origins

The Service Delivery Review (SDR) emerged from the Kanban Method as developed by David J. Anderson¹. Anderson framed software teams as services with customers, commitments, and obligations. The SDR is the cadence designed to ask whether the service is actually meeting those obligations — not "how is the team doing" in some abstract sense, but "is the customer of this service getting what they paid for."

The pattern complements operational and process reviews. Service delivery review sits at the customer interface; operations review sits at the team-internal flow; risk review sits across the portfolio. Each has a different scope and a different audience.

What an SDR Examines

The Service Delivery Review focuses on the service's external performance — how the customer of the service experiences it. The questions are concrete:

• Are we meeting our service-level expectations? Cycle time within target, throughput steady, lead-time predictability acceptable.
• What is the quality of what we delivered? Defect rates, escaped bugs, customer complaints, incident rates.
• Are we honoring our commitments? Fixed-date items delivered on time, expedites handled appropriately, intangible work balanced.
• What did the customer ask us to do versus what we did? Demand patterns, request rejection rates, mismatch between expectation and outcome.

Notably absent: how the team feels, what the team is reading, the team's internal practice changes. Those belong to other cadences. The SDR is customer-facing.

Who Is in the Room

An SDR includes the people on the producing side and the receiving side of the service. For a typical software team:

• Service team representatives (often Product Manager and a senior engineer or tech lead).
• Key customers of the service (other teams that consume the service, business stakeholders, sometimes end users).
• A facilitator who keeps the conversation customer-focused.

The participant mix is the key constraint. An SDR where only the team is present is not a service delivery review — it is just a status meeting. Without the customer side represented, the review can't actually check whether expectations are being met.

The Cadence

Anderson recommends a fixed monthly cadence for most teams. The right frequency depends on the speed of the service:

• Fast-cycle services (e.g., daily delivery): biweekly SDRs.
• Typical software teams (weekly to monthly delivery): monthly SDRs.
• Longer-cycle services or research-style work: quarterly SDRs may make sense.

The cadence should be regular and predictable. Customers learn when the conversation will happen and prepare for it; the team's data collection rhythm aligns with the review.

A Typical Agenda

1. State of service (10 min)

The team walks through the headline metrics: cycle time, throughput, blocker patterns, defect trends. Visualization (CFD, throughput chart) is the artifact, not the slide deck.

2. Commitments and outcomes (10 min)

What the team committed to since the last SDR, what shipped, what slipped. Honest accounting, not selective highlighting.

3. Customer feedback (15 min)

The customer side speaks. What worked, what didn't, what they need that they're not getting. The team listens before responding.

4. Pattern observations (10 min)

The team and customer together identify recurring patterns. Are the same item types always slow? Are certain customers consistently underserved? Where is the friction?

5. Adjustments and commitments (10 min)

Specific things the service or its customers will change before the next SDR. Owned, time-boxed, agreed.

What Makes SDRs Useful

• Real customer representation: the service's actual customers attend, not internal proxies.
• Data-driven conversation: flow metrics, defect data, and incident records anchor the discussion in evidence rather than impression.
• Honest accounting: misses and quality problems get named, not glossed.
• Symmetric obligation: customers commit to changes too — clearer requirements, better-staged demands, faster sign-off — not just the service team.
• Outcome-oriented: ends with specific changes, not just discussion.

Common Pitfalls

• Status meeting in disguise: SDR without real customers becomes a slide review. Make sure the customer side is genuinely represented.
• Selective metrics: showing only the favorable charts. The customer notices, and the SDR loses credibility.
• One-way commitments: every change owned by the service team, none by customers. Symmetric obligation is what makes the conversation real.
• Missing follow-up: commitments made, never tracked, never revisited. The next SDR's first agenda item should be "what we said we'd do last time."
• Wrong scope: trying to make the SDR also be the operations review and the team retro. Use separate cadences for separate questions.

Coaching Tips

Insist on Customer Presence

If real customers aren't in the room, it's a different meeting. Reschedule rather than run an SDR without them.

Show the Uncomfortable Data

Misses, slow items, escaped defects. Hiding bad data destroys the review's credibility. Show the truth and discuss what to do about it.

Negotiate Symmetric Commitments

If only the team commits to changes, the SDR becomes one-sided. Push for customer-side commitments too — clearer requests, faster approvals, fewer expedites.

Track Last Time's Promises

Open every SDR by reviewing what was committed to last time. Without that loop, the review produces promises that nobody honors.

Use Real Flow Data

Cycle time histograms and CFDs anchor the conversation. Without data, the SDR slides into anecdotes and impression.

Don't Conflate Cadences

If the SDR is being asked to also serve as retro and ops review, the conversation gets muddy. Run separate sessions for separate audiences.

Summary

The Service Delivery Review fills a gap most teams don't realize they have. Retros are internal; operations reviews are internal; sprint reviews demo the work but don't necessarily examine the service contract. The SDR brings the producing side and the receiving side together to ask whether the service is actually delivering what its customers need.

It works when the customer side is genuinely present and the conversation is genuinely two-way. It fails when it becomes a slide deck or a status update. The discipline is to treat the team as a service with obligations to its customers, and the review as the cadence where those obligations get examined honestly.

Back to DevOps