HKSM

Key Points

• Output of Create Deliverables and input to Demonstrate and Validate Sprint.
• Consist of completed user stories and the integrated product increment.
• Must satisfy the Definition of Done and agreed acceptance criteria.
• Reviewed with stakeholders in the Sprint Review for acceptance by the Product Owner.
• Drive updates to the Product Backlog, release planning, and metrics.
• Accepted items may be shipped or staged per the release plan.

Purpose

The goal is to provide a tangible, potentially shippable increment that demonstrates value delivered in the sprint. This enables inspection of the product, validation against acceptance criteria, and informed decisions on release readiness or further refinement.

Key Terms & Clauses

• Product increment: The sum of all completed work in the sprint integrated with prior increments.
• User story and acceptance criteria: The scope and checks that guide development and validation.
• Definition of Done (DoD): Quality and completion standard for each deliverable.
• Done vs. Undone work: Only Done items belong in Sprint Deliverables; undone work returns to the Product Backlog.
• Product Owner acceptance: The decision to accept or reject items based on criteria and DoD.
• Supporting assets: Tests, documentation, configuration, and deployment scripts that make the increment usable.

How to Develop/Evaluate

Develop:

• Break selected user stories into tasks, implement, integrate, and test continuously.
• Apply the DoD to code, tests, documentation, and nonfunctional requirements.
• Maintain transparency via Daily Standup, boards, and visible builds.
• Keep work in small, vertical slices that can be demonstrated end-to-end.

Evaluate:

• Verify acceptance criteria, run automated and exploratory tests, and confirm integration.
• Ensure no critical defects remain and technical debt is within agreed limits.
• Prepare demo scenarios and data for Sprint Review; capture feedback and variances.

How to Use

• Present in the Sprint Review during Demonstrate and Validate Sprint for acceptance decisions.
• Feed accepted items into Ship Deliverables or release planning based on strategy.
• Update the Product Backlog with new stories, enhancements, or defects discovered.
• Inform progress metrics such as burn-up, velocity, and release forecasts.
• Use as inputs to Retrospect Sprint to discuss quality, flow, and improvement actions.

Example Snippet

At sprint end, the team integrates three completed user stories: registration, password reset, and audit logging. All meet the DoD, pass automated and acceptance tests, and are ready to demo to stakeholders. The Product Owner reviews them in the Sprint Review, accepts two for immediate release, and requests a minor change to audit logging, which is added as a new Product Backlog Item.

Risks & Tips

• Risk: Hidden work not covered by the DoD leads to rework. Tip: Strengthen and socialize the DoD.
• Risk: Integration surprises late in the sprint. Tip: Integrate and test continuously with CI pipelines.
• Risk: Vague acceptance criteria cause disputes. Tip: Clarify criteria during backlog refinement.
• Risk: Overcommitment reduces quality. Tip: Forecast using empirical velocity and enforce WIP discipline.
• Risk: Demo-only increments without operability. Tip: Include deployment, observability, and documentation in DoD.
• Risk: Stakeholder disengagement. Tip: Schedule focused reviews and share pre-demo builds for early feedback.

PMP/SCRUM Example Question

During Sprint Review in a SBOK-aligned project, which artifact should be the primary input to Demonstrate and Validate Sprint for acceptance decisions?

1. Prioritized Product Backlog.
2. Sprint Deliverables.
3. Release Planning Schedule.
4. Impediment Log.

Correct Answer: B — Sprint Deliverables

Explanation: The review inspects the completed increment and user stories produced in the sprint. Sprint Deliverables are presented for validation and acceptance by the Product Owner.