HKSM

Ship Deliverables is the process of formally releasing accepted, Done increments to the customer or production environment with complete packaging, deployment, documentation, and handover to operations/support.

Purpose & When to Use

This process takes increments that meet the Definition of Done and have been accepted by the Product Owner and moves them into the customer or production environment. It ensures release readiness, smooth deployment, proper communication, and handover to operations and support.

Use it at the end of any Sprint or grouped release when the Product Owner decides the increment provides enough value to go live. It is triggered after acceptance, when compliance/risk checks are satisfied and a deployment window is available.

Mini Flow (How It’s Done)

• Confirm readiness: All items in the release meet Definition of Done; Product Owner has accepted the increment; release scope, risks, and dependencies are confirmed.
• Plan the release: Choose deployment strategy (e.g., blue-green, canary, phased), finalize the deployment checklist, rollback plan, migration scripts, and release notes; align on timing with change windows.
• Prepare artifacts: Version/tag the build and infrastructure-as-code, package deliverables, create user documentation, support runbooks, and training materials; verify environment parity.
• Obtain approvals: Get Product Owner sign-off, any required change/advisory approvals, and necessary legal/compliance confirmations.
• Execute deployment: Back up relevant data, freeze non-critical changes, deploy to production, perform smoke tests and data migrations, and enable monitoring/alerts.
• Communicate and train: Publish release notes, notify stakeholders and customers, deliver training or quick-start guides, and update service catalogs.
• Handover to support: Transfer runbooks, escalation paths, and SLAs to operations; initiate a stabilization/warranty period.
• Close the release: Capture metrics (defects, release lead time, change failure rate), document known issues and workarounds, update the Product Backlog with follow-ups, and archive baselines.

Quality & Acceptance Checklist

• All release items are Done and accepted by the Product Owner.
• Regression, security, performance, and usability tests passed in a production-like environment.
• Compliance/privacy checks and license obligations completed with auditable evidence.
• Data migration rehearsed and validated; integrity checks defined.
• Rollback/restore procedures documented, tested, and time-boxed.
• Monitoring, logging, and alerting configured with clear on-call ownership.
• Backups taken and verified; configuration and build artifacts are versioned and traceable.
• Release notes, user guides, and support runbooks are complete and published.
• Change window approved; dependencies and third-party readiness confirmed.
• Known issues and workarounds documented; acceptance and operational sign-offs recorded.

Common Mistakes & Exam Traps

• Equating “potentially shippable” with “must ship now.” The Product Owner decides whether to release.
• Shipping without Product Owner acceptance or without meeting the Definition of Done.
• Ignoring non-functional requirements (security, performance, compliance) that can fail a release.
• Skipping rollback validation or forgetting backups before deployment.
• Confusing Sprint Review (demonstration) with shipping (deployment to customers/production).
• Underestimating operations needs: change approvals, monitoring, support readiness, and documentation.
• Big-bang releases when incremental or phased rollouts would reduce risk.
• Failure to capture post-release issues and learning into the Product Backlog and metrics.

PMP/SCRUM Example Question

After the Product Owner accepts the increment in the Sprint Review, operations requires a formal change window and evidence of a tested rollback. What should the Scrum Team do next as part of Ship Deliverables?

1. Assemble the release package with versioned artifacts, release notes, and a validated rollback; obtain necessary approvals and schedule within the change window.
2. Deploy immediately to production to maximize fast feedback, then create the rollback plan if issues appear.
3. Schedule a hardening Sprint to address any potential defects before seeking approvals.
4. Ask the Product Owner to add more features to increase release value before starting any deployment work.

Correct Answer: A. The team should package the release, validate rollback, secure required approvals, and deploy within the agreed window; the other options either add non-Scrum delays, skip risk controls, or prioritize scope over readiness.