The sprint review is a collaborative inspection of the increment delivered during the sprint. Lasting approximately one hour for a two-week sprint, this ceremony brings the development team together with stakeholders to demonstrate working software, gather feedback, and discuss how the product backlog should adapt based on what was learned.
Unlike a formal presentation, the sprint review is meant to be an interactive working session. Stakeholders see real functionality, ask questions, suggest changes, and help the product owner reprioritise upcoming work. The goal is not approval; it is alignment. The team shows what they built, the stakeholders share whether it meets their needs, and the product owner updates the backlog accordingly.
When done well, the sprint review creates a tight feedback loop between the people building the product and the people who will use or sell it. It pairs naturally with the sprint retrospective, which examines how the team worked rather than what they built. This reduces the risk of building the wrong thing and ensures that the product evolves based on genuine stakeholder input rather than assumptions.
The sprint review belongs at the end of every sprint. It is especially important when:
| Role | Responsibility |
|---|---|
| Product Owner | Open the review with a summary of the sprint goal, confirm which items were completed versus carried over, and facilitate backlog discussion. |
| Development Team | Demonstrate completed features using working software. Answer technical questions and explain any trade-offs made during implementation. |
| Scrum Master / Facilitator | Keep the session on schedule, ensure all demos are covered, and manage the discussion flow so feedback is captured without derailing. |
| Key Stakeholders | Provide feedback on demonstrated features, share evolving business context, and help the product owner assess priorities for upcoming sprints. |
| Designers | Evaluate the implemented experience against the original design intent and note any visual or interaction adjustments needed. |
| Customer Representatives (optional) | Offer end-user perspective on the demonstrated features, validating that the solution meets real-world needs. |
| Duration | Activity | Notes |
|---|---|---|
| 5 min | Sprint goal recap and completion summary | Product owner states the goal, lists completed items, and notes anything that was not finished |
| 5 min | Sprint metrics overview | Share velocity, burndown trends, and any relevant quality metrics (bug counts, test coverage changes) |
| 30 min | Feature demonstrations | Team members demo each completed item using the staging or production environment. Use realistic data and scenarios. |
| 10 min | Stakeholder feedback and questions | Open the floor for reactions. Capture feedback as backlog items rather than debating solutions on the spot. |
| 10 min | Backlog and roadmap implications | Product owner discusses how feedback and sprint outcomes affect priorities for the next sprint planning session and beyond |
An e-commerce team has just completed a sprint focused on a redesigned checkout flow. The sprint goal was to reduce cart abandonment by simplifying the payment step from three pages to one. The team built a single-page checkout with inline address validation, saved payment methods, and a real-time order summary.
During the demo, the front-end developer walks through the new flow using a test account. She shows how the address autocomplete reduces typing, how saved cards appear for returning users, and how the order summary updates instantly when a promo code is applied. The head of marketing notices that the promo code field is buried below the fold and suggests moving it higher. The product owner captures this as a new backlog item.
The design lead flags that the mobile layout compresses the payment icons too tightly, making them hard to tap. This is also captured. By the end of the review, the team has validated the core flow with stakeholders, identified two refinements, and the product owner has already prioritised the promo code repositioning for the next sprint. Without this review, those issues might have gone unnoticed until after launch.