A time-boxed end-of-Sprint event where the team demonstrates working product to the Product Owner and stakeholders to verify acceptance criteria, gain formal acceptance, and capture feedback for the backlog.

Purpose & When to Use

This process ensures the increment built in the Sprint is inspected as working software and validated against agreed acceptance criteria and the Definition of Done. It is used at the end of every Sprint to obtain Product Owner acceptance, capture stakeholder feedback, update the Prioritized Product Backlog, and adjust release expectations based on real progress and value delivered.

Use it whenever the team has potentially shippable features to show. The focus is on outcomes and functionality, not status slides or theoretical designs.

Mini Flow (How It’s Done)

• Prepare the demo: integrate completed user stories, run smoke/regression tests, line up test data, and confirm the demo environment mirrors production-like conditions.
• Set the context: Scrum Master facilitates; Product Owner confirms goals and the scope planned for this Sprint.
• Demonstrate working product: Developers show each completed user story end-to-end, mapping what’s shown to the acceptance criteria; cover key non-functional expectations (performance, security, accessibility) where relevant.
• Validate and decide: Product Owner accepts or rejects each item based on acceptance criteria and Definition of Done; record any defects or gaps.
• Capture feedback: note enhancements, questions, and new ideas as new or updated backlog items without expanding the current Sprint scope retroactively.
• Update artifacts: mark accepted stories as Done, return unaccepted items to the Prioritized Product Backlog, adjust release forecasts/velocity, and record decisions and follow-ups.
• Close-out: confirm next steps (e.g., readiness for release, needed fixes), and move on to the Sprint Retrospective to improve the process.

Quality & Acceptance Checklist

• Each demonstrated item maps to a user story or backlog item with clear acceptance criteria.
• Definition of Done is met: code complete, peer reviewed, integrated, tested, and potentially shippable.
• Automated tests pass; critical and high defects are resolved or explicitly captured as new backlog items.
• End-to-end flow shown with realistic data; performance and security checks considered where applicable.
• Product Owner’s acceptance recorded per item (accepted/rejected with reason).
• Documentation updated as needed (user help, release notes, architecture decisions, test evidence).
• Backlog updated: unaccepted work returned and reprioritized; new feedback captured as items, not as hidden scope.
• Metrics refreshed: velocity, burn-up/burn-down, and release forecast reflect actual acceptance.

Common Mistakes & Exam Traps

• Confusing this event with the Sprint Retrospective: this one inspects the product; the retrospective inspects the process.
• Showing slides instead of working software; acceptance must be based on a functioning increment.
• Allowing scope creep during the meeting; feedback becomes new or updated backlog items for future Sprints.
• Accepting a story that fails any acceptance criterion or Definition of Done because it is “mostly done.”
• Not inviting the right stakeholders, leading to late surprises and rework.
• Skipping non-functional expectations (e.g., performance) that were part of acceptance criteria.
• Failing to update the backlog and release plan after acceptance/rejection decisions.
• Extending the Sprint to “finish” rejected items instead of returning them to the backlog.

PMP/SCRUM Example Question

During Demonstrate and Validate Sprint, one user story works functionally but misses its response-time target specified in the acceptance criteria. What should the team do next?

1. Mark the story Done since functional behavior is correct and address performance later in the Retrospective.
2. Split the story and accept the functional part now, with a change request for performance in the same Sprint.
3. Do not mark it Done; return it to the Prioritized Product Backlog (or create a defect) and reprioritize it for a future Sprint.
4. Extend the Sprint to fix the performance issue so the story can be accepted.

Correct Answer: C. The story does not meet its acceptance criteria/Definition of Done; it should not be accepted. It returns to the backlog (often as a defect or updated story) for reprioritization in a future Sprint; the Sprint time-box is not extended.