HKSM

A time-boxed event at the end of each Sprint where the team demonstrates the working Increment to stakeholders, gathers feedback, and decides what to do next. It is used to inspect the product and adapt the Product Backlog and release plans based on real results and stakeholder input.

Key Points

• Held at the end of each Sprint and time-boxed (up to 4 hours for a one-month Sprint).
• Attendees include Product Owner, Scrum Master, Development Team, and key stakeholders.
• Demonstrates a working Increment that meets the Definition of Done.
• Product Owner evaluates acceptance criteria and accepts or rejects completed user stories.
• Product Backlog ordering and release plans are updated based on feedback and market insights.
• Focuses on product value and future direction; it is not the Sprint Retrospective.

Purpose of Analysis

The meeting exists to inspect the Increment and analyze stakeholder feedback, progress toward the product vision, and market or operational changes. Insights gained guide decisions about what to build next, how to reorder the Product Backlog, and how to adjust release targets to maximize value.

It enables transparent review of outcomes against the Sprint Goal and acceptance criteria, ensuring that future work aligns with stakeholder needs and organizational strategy.

Method Steps

1. Prepare the demo: ensure the Increment is integrated, stable, and ready to show in a production-like environment.
2. Set context: Scrum Master facilitates; Product Owner states the Sprint Goal and what was planned versus completed.
3. Demonstrate the Increment: Development Team shows working features, walking through user stories and acceptance criteria.
4. Collect feedback: stakeholders ask questions, suggest enhancements, and discuss business value and market impact.
5. Acceptance decisions: Product Owner accepts or rejects completed items based on the agreed criteria.
6. Adapt plans: discuss likely next items, adjust ordering, and consider release implications.
7. Record actions: capture new or changed backlog items, risks, dependencies, and follow-ups.

Inputs Needed

• Working Increment that meets the Definition of Done.
• Completed user stories with acceptance criteria and test results.
• Sprint Goal, Sprint Backlog status, and relevant metrics (e.g., completed points).
• Product Backlog and current ordering, including epics and upcoming stories.
• Demo environment, data, and access for stakeholders.
• Stakeholder availability and any market, compliance, or customer updates.

Outputs Produced

• Updated Product Backlog with new items, refined details, and revised ordering.
• Acceptance or rejection decisions for demonstrated user stories.
• Adjustments to release plans, forecasts, or roadmap based on feedback and Increment status.
• Documented feedback, risks, dependencies, and action items.
• Shared understanding of product value delivered and potential next steps.

Interpretation Tips

• Emphasize outcomes and value, not status reporting; show working software and real results.
• Tie discussions to the Sprint Goal and acceptance criteria to keep conversations objective.
• Invite the right stakeholders who can provide actionable feedback and decisions.
• Use insights to reorder the Product Backlog immediately, keeping it transparent and current.
• Differentiate this event from the Sprint Retrospective: this meeting is product-focused and outward-facing.

Example

A team completes five user stories in the Sprint. During the Sprint Review, they demonstrate the new search feature, show performance results, and confirm that accessibility criteria were met.

Stakeholders request a filter enhancement and note a regulatory update. The Product Owner adds a new backlog item for the filter, raises a compliance task, and reorders the next Sprint’s candidates to reflect the highest value and urgency.

Pitfalls

• Turning the session into a slide-driven status meeting instead of demonstrating working features.
• Failing to include key stakeholders, resulting in late or weak feedback.
• Skipping acceptance criteria, leading to unclear acceptance decisions.
• Attempting to change the current Sprint scope or extend the timebox to squeeze in new work.
• Not updating the Product Backlog and release plan promptly after receiving feedback.

PMP/SCRUM Example Question

During a Sprint Review, stakeholders request a high-value enhancement they believe can be built in two days next week. What should the Product Owner do?

1. Change the current Sprint scope to include the enhancement.
2. Add the enhancement as a Product Backlog item and reorder it for the next Sprint based on value.
3. Schedule a separate approval gate before allowing it into the Product Backlog.
4. Ask the Scrum Master to extend the Sprint by two days to deliver it now.

Correct Answer: B — Add the enhancement as a Product Backlog item and reorder it for the next Sprint based on value.

Explanation: The Sprint Review is used to gather feedback and adapt the Product Backlog and release plans. The current Sprint timebox is not changed; new work is prioritized for future Sprints.