HKSM

Outputs from Demonstrate and Validate Sprint are the documented results of the Sprint Review in SBOK: accepted deliverables, rejected items with reasons, stakeholder feedback, and related updates. These outputs become inputs to Ship Deliverables, Retrospect Sprint, backlog refinement, and upcoming planning.

Key Points

• Created at the end of the Sprint Review within the Demonstrate and Validate Sprint process.
• Contain acceptance decisions recorded by the Product Owner against acceptance criteria and Definition of Done.
• List accepted deliverables and rejected or deferred items with clear reasons and defects, if any.
• Capture stakeholder feedback, change requests, and new or updated user stories for the prioritized product backlog.
• May include updates to release notes, version tags, and a go/no-go recommendation for release.
• Serve as inputs to Ship Deliverables, Retrospect Sprint, Groom Prioritized Product Backlog, and planning for the next sprint.

Purpose

The outputs give a transparent, auditable record of what was demonstrated and what was accepted. They help the Product Owner and stakeholders make informed release decisions and ensure shared understanding of remaining work.

They also provide structured feedback that flows into backlog refinement and set up the team for targeted improvements in the Retrospect Sprint process.

Key Terms & Clauses

• Accepted deliverables: User stories or backlog items that meet acceptance criteria and Definition of Done and are approved by the Product Owner.
• Rejected or deferred items: Stories that do not meet acceptance criteria; returned to the prioritized product backlog with documented reasons and defects.
• Acceptance record/sign-off: Evidence of approval (e.g., checklist, notes, screenshots, or sign-off form) tied to story IDs.
• Stakeholder feedback: Observations, enhancement ideas, and new requirements captured during the review.
• Change requests/new user stories: Formalized backlog entries created from feedback and gaps.
• Release updates: Draft release notes, version identifiers, and readiness status for Ship Deliverables.

How to Develop/Evaluate

1. Prepare a demo checklist mapped to user stories, acceptance criteria, and Definition of Done.
2. During the review, have the Product Owner evaluate each story against acceptance criteria and record pass/fail with notes.
3. Capture evidence (screenshots, links, test results) and link it to story IDs for traceability.
4. Classify outcomes as accepted, rejected, or deferred; log defects and reasons for any rejection.
5. Convert feedback into refined user stories or change requests with clear acceptance criteria and initial sizing notes.
6. Draft or update release notes and readiness status if a release is being considered.

How to Use

• Feed accepted deliverables to the Ship Deliverables process for packaging, deployment, or customer release.
• Return rejected items to the prioritized product backlog; refine, re-estimate, and schedule in future sprints.
• Input feedback-derived user stories into Groom Prioritized Product Backlog for prioritization by the Product Owner.
• Share outcomes with the team and stakeholders; update dashboards, velocity, and release plans.
• Bring the outcome summary into Retrospect Sprint to discuss what helped or hindered acceptance.

Example Snippet

Example output set from a Sprint Review:

• Accepted deliverables: US-104 search filter, US-109 role-based access; DoD met; signed by Product Owner.
• Rejected items: US-111 export function - fails edge case; defect DF-32 logged; returned to backlog.
• Feedback: Add CSV export preset and audit log view; created stories US-115 and US-116.
• Release updates: Draft notes v2.3 prepared; readiness status green for accepted items.

Risks & Tips

• Risk: Ambiguous acceptance criteria lead to disputes. Tip: Write clear, testable criteria before development and validate with examples.
• Risk: Missing sign-off delays release. Tip: Capture Product Owner approval during the review with a simple checklist and evidence links.
• Risk: Scope creep via feedback. Tip: Treat feedback as new backlog entries and prioritize transparently; do not expand the current sprint scope.
• Risk: Defects are not traced back. Tip: Link each rejection to a defect or task and reference the original story ID.
• Risk: Poor visibility across teams. Tip: Publish a concise summary of accepted/rejected items and release readiness on shared dashboards.

PMP/SCRUM Example Question

In SBOK terms, which artifact is included in the outputs from Demonstrate and Validate Sprint and becomes an input to Ship Deliverables?

1. Agreed action items for improvement.
2. Accepted deliverables.
3. Updated Sprint Burndown Chart.
4. Detailed task estimates for the next sprint.

Correct Answer: B — Accepted deliverables

Explanation: Accepted deliverables are approved by the Product Owner during the Sprint Review and flow directly into Ship Deliverables. Action items come from the Retrospect Sprint, and the other options are not primary outputs of this process.