Overview¶

Release management — deciding what, when, and how to ship to production or customers — is often under-addressed in introductory Scrum training, which focuses mainly on the Sprint cadence. This guide covers release strategy across both Scrum (fixed-cadence) and Kanban (continuous-flow) team structures.

Who it's for: Scrum Masters, Release Managers, and Product Owners responsible for coordinating what ships and when.

Core Topics Breakdown¶

1. Decoupling "Done" from "Released"¶

• A Sprint Increment being "Done" (meets the Definition of Done) does not necessarily mean it's released to customers — many organizations batch releases for business reasons (marketing coordination, compliance windows, customer training).
• Feature flags/toggles let teams merge and deploy code continuously while controlling release (customer visibility) independently — a key technique for decoupling deployment from release.

2. Release Strategies¶

• Continuous deployment: every change that passes automated checks goes to production automatically — requires mature CI/CD and strong automated test coverage.
• Scheduled/batched releases: accumulating several Sprints' worth of Increments into a single coordinated release — common in regulated industries or when customer-facing change management is required.
• Canary releases: rolling a new feature out to a small subset of users first, monitoring for issues, before a full rollout — reduces blast radius of defects.
• Blue-green deployment: maintaining two production environments and switching traffic between them, enabling near-instant rollback if a release causes problems.

3. Release Planning in Scrum¶

• Multi-Sprint release planning: forecasting which Sprint a release-worthy set of features will be ready, using historical velocity as an input (with appropriate uncertainty ranges).
• Release Sprint anti-pattern: dedicating an entire Sprint purely to "stabilization" before a release is often a sign that quality/testing isn't sufficiently built into every Sprint (violates Lean's "build integrity in" principle).

4. Release Planning in Kanban¶

• Since Kanban has no fixed Sprint cadence, releases are typically triggered by either a fixed calendar schedule or by accumulated value/risk thresholds (e.g., "release once 10 customer-requested items are done").
• Class-of-service policies (e.g., "expedite" lane for urgent fixes) directly affect how quickly an item can reach a release-ready state outside the normal flow.

5. Release Risk Management¶

• Maintaining a rollback plan for every release, not just major ones — the cost of preparing a rollback is far lower than the cost of an unplanned outage without one.
• Post-release monitoring windows: defining what "success" looks like after a release (error rates, performance metrics, customer support ticket volume) and who's responsible for watching them.
• Communicating release notes to both internal stakeholders and customers in appropriately different levels of technical detail.

Study Tips¶

• Practice explaining the distinction between "deployed" and "released" with a concrete feature-flag example — this is a frequently tested and frequently misunderstood distinction.
• Compare and contrast canary releases vs. blue-green deployment: both reduce risk, but through different mechanisms (gradual exposure vs. instant environment switch).
• Be able to describe a full release checklist for a hypothetical feature: Definition of Done met → feature flag configured → rollback plan documented → monitoring dashboard ready → release notes drafted.

Common Pitfalls¶

• Treating "Done" and "released" as synonyms, which creates confusion about what stakeholders should expect to actually see live.
• Skipping rollback planning for "small" releases, which are often exactly the releases that get rushed and cause unexpected issues.
• Batching too many changes into a single release, making it hard to isolate the root cause if something breaks post-release.

Quick Reference Cheat Sheet¶

Further Practice¶

Design a release plan for a hypothetical feature: specify the release strategy (continuous, batched, canary), the rollback plan, and the post-release metrics you'd monitor for the first 48 hours.