---
title: "Sprint Review Template"
methodology: "agile"
complexity: "advanced"
owner: "mirichard"
updated: "2026-09-19"
primary_principles: ["stakeholder-engagement", "adaptability"]
secondary_principles: ["value-focus"]
principle_rationale: "Invites stakeholders and the team to inspect the increment and use outcome feedback to adapt product priorities."
---

# SPRINT REVIEW

## When to Use

- At a Sprint Review when stakeholders and the team inspect outcomes and adapt direction.
- When feedback on the increment can change product priorities.

## When NOT to Use

- As a presentation-only status meeting or a required release gate.
- Do not represent attendance, distribution, or silence as stakeholder agreement. See [Stakeholder broadcast](../../../../docs/principles/anti-patterns.md#stakeholder-broadcast).

## Pairs Well With

- [Product Backlog Template](../../../../domains/delivery/templates/agile/product_backlog_template.md).
- [Agile Stakeholder Map Template](../../../../domains/stakeholder/project-lifecycle/01-initiation/stakeholder-analysis/agile-stakeholder-map-template.md).

Selection context: Team domain; agile methodology; advanced complexity. Match the situations above to project phase, risk, team size, and industry using the [decision-engine context model](../../../../meta/architecture-research/800-801-context-assessment-model.md).

## Scrum tailoring

These worksheets and suggested agendas are optional practices. In Scrum, the Developers own the plan for delivering the Sprint Goal; selected work is a forecast that can be adapted. A Definition of Ready and story points are optional team practices. Use the product Definition of Done consistently, and treat the Sprint Review as inspection and adaptation rather than a release-approval gate. See the [Scrum Guide](https://scrumguides.org/scrum-guide.html).


## Document Information
**Product/Project Name:** *[Customer Portal Application]*  
**Sprint Number:** *[Sprint 5]*  
**Sprint Dates:** *[YYYY-MM-DD to YYYY-MM-DD]*  
**Review Date and Time:** *[YYYY-MM-DD, HH:MM - HH:MM]*  
**Location/Platform:** *[Conference Room / Virtual Platform]*  
**Scrum Master:** *[John Doe]*  
**Product Owner:** *[Jane Smith]*  
**Last Updated:** *[YYYY-MM-DD]*\

---

## Document Purpose
*This Sprint Review document serves as both a preparation guide and a record of the Sprint Review meeting for Sprint [X]. It outlines the structure of the review, the achievements of the sprint, demonstration scenarios, stakeholder feedback, and implications for future work. This document helps the team prepare for an effective review and captures important information for future reference.*

---

## Table of Contents
1. [Sprint Review Meeting Structure](#1-sprint-review-meeting-structure)
2. [Sprint Goal Achievement](#2-sprint-goal-achievement)
3. [Demo Preparation](#3-demo-preparation)
4. [Demonstration Scenarios](#4-demonstration-scenarios)
5. [Stakeholder Feedback](#5-stakeholder-feedback)
6. [Product Backlog Implications](#6-product-backlog-implications)
7. [Release Planning Updates](#7-release-planning-updates)
8. [Key Metrics Review](#8-key-metrics-review)
9. [Action Items](#9-action-items)
10. [Next Steps](#10-next-steps)

---

## 1. Sprint Review Meeting Structure

### 1.1 Meeting Logistics
- **Date and Time:** *[YYYY-MM-DD, HH:MM - HH:MM]*
- **Location:** *[Meeting Room / Virtual Platform]*
- **Duration:** *[2 hours maximum]*
- **Facilitator:** *[Usually the Scrum Master]*

### 1.2 Attendees

#### Core Team (Required)
- **Development Team:** *[List all team members]*
- **Scrum Master:** *[Name]*
- **Product Owner:** *[Name]*

#### Key Stakeholders (Invited)
- *[Name, Role/Department]*
- *[Name, Role/Department]*
- *[Name, Role/Department]*
- *[Name, Role/Department]*

### 1.3 Agenda

| Time | Activity | Presenter | Description |
|------|----------|-----------|-------------|
| *00:00 - 00:05* | Welcome and Introduction | *Scrum Master* | Welcome attendees, explain meeting purpose and format |
| *00:05 - 00:15* | Sprint Goal Review | *Product Owner* | Recap sprint goal and overall achievement |
| *00:15 - 00:20* | Sprint Metrics Overview | *Scrum Master* | Quick review of velocity, scope changes, and quality metrics |
| *00:20 - 01:15* | Feature Demonstrations | *Dev Team* | Demonstrate completed features with stakeholder interaction |
| *01:15 - 01:35* | Feedback and Discussion | *All* | Gather inputs and insights from stakeholders |
| *01:35 - 01:50* | Product Backlog and Release Plan Update | *Product Owner* | Discuss implications for product backlog and upcoming releases |
| *01:50 - 02:00* | Wrap-up and Next Steps | *Scrum Master* | Summarize key points and action items |

### 1.4 Meeting Guidelines

- Keep the atmosphere informal and collaborative
- Focus on the completed product increment and working functionality
- Encourage questions and interactions during demonstrations
- Maintain a timebox for each section to ensure all content is covered
- Capture feedback and suggestions without immediately committing to them
- Avoid detailed technical discussions (defer to separate meetings)
- Ensure everyone has a chance to participate
- Document decisions and action items clearly

---

## 2. Sprint Goal Achievement

### 2.1 Sprint Goal
*Copy the sprint goal from sprint planning*

*Example: "Deliver a fully functional user authentication system that allows users to register, log in, reset passwords, and manage their profiles, enabling secure access to the customer portal."*

### 2.2 Achievement Assessment

| Aspect | Status | Comments |
|--------|--------|----------|
| Overall Goal Achievement | *Fully Achieved / Partially Achieved / Not Achieved* | *Brief explanation* |
| Key Functionality Delivered | *List Key Functions* | *Notes on delivery state* |
| Functionality Not Delivered | *List if any* | *Reasons and impact* |
| Added Scope | *List if any* | *Justification for additions* |
| Quality Objectives | *Met / Partially Met / Not Met* | *Quality assessment notes* |

### 2.3 Sprint Narrative
*Provide a brief narrative of the sprint journey, highlighting successes, challenges, and how the team responded to them.*

*Example: "The team successfully delivered all core authentication functionality as planned. We encountered unexpected complexity with the password reset flow, which required additional security measures not initially identified. The team responded by re-prioritizing tasks and focusing on core functionality first. The additional security enhancements were implemented efficiently without compromising the sprint goal. Overall, the sprint was successful with all critical functionality delivered to a high quality standard."*

---

## 3. Demo Preparation

### 3.1 Demo Environment Setup
*Document the environment where the demonstration will take place and any setup requirements.*

#### Environment Details
- **Demo Environment:** *[Development / Staging / Production]*
- **Access URL:** *[https://demo.example.com]*
- **Test Accounts:**
  - *Admin User: admin@example.com / demo-password*
  - *Regular User: user@example.com / demo-password*
  - *New User Registration: Will be created during demo*

#### Technical Setup
- **Equipment Needed:**
  - *Presenter laptop with access to demo environment*
  - *Projector/Screen sharing capability*
  - *Stable internet connection*
  - *Backup demonstration option (screenshots/video if live demo fails)*

### 3.2 Demo Preparation Checklist

#### Technical Preparation
- [ ] Demo environment is stable and accessible
- [ ] All features to be demonstrated are deployed and working
- [ ] Test accounts are set up with appropriate data
- [ ] Test runs completed to verify all demo scenarios
- [ ] Browser cache cleared to ensure fresh experience
- [ ] Network connectivity verified
- [ ] Backup demo option prepared (screenshots, video)
- [ ] Screen sharing or projection equipment tested

#### Content Preparation
- [ ] Demo scenarios documented with specific steps
- [ ] User stories and acceptance criteria on hand for reference
- [ ] Roles assigned for different parts of the demonstration
- [ ] Transitions between presenters planned
- [ ] Time allocated appropriately for each scenario
- [ ] "Wow" moments identified and highlighted
- [ ] Potential questions anticipated with prepared answers
- [ ] Known limitations or issues documented (if relevant)

### 3.3 Demonstration Best Practices

- **Tell a Story**: Structure demos around user journeys rather than features
- **Use Real-World Scenarios**: Demonstrate how users would actually use the system
- **Show, Don't Tell**: Minimize explanations, maximize showing working functionality
- **Involve the Audience**: Invite questions and suggestions during or after each scenario
- **Avoid Bugs**: Stick to well-tested paths for the main demonstration
- **Be Honest**: If something doesn't work, acknowledge it and move on
- **Highlight Value**: Emphasize the business value of each feature
- **Keep It Simple**: Avoid technical jargon and complex explanations
- **Plan for Questions**: Allow time for discussion after each scenario
- **Have a Backup Plan**: Be prepared for technical difficulties

---

## 4. Demonstration Scenarios

*Detail the specific scenarios that will be demonstrated during the review. Each scenario should be based on completed user stories and demonstrate value to stakeholders.*

### 4.1 Scenario 1: New User Registration

**User Story Reference:** *US-101*

**Business Value:** *Allows new users to create accounts and access the platform, expanding our user base.*

**Demonstrator:** *Alex Smith*

**Demonstration Flow:**
1. Start at the application home page
2. Click "Sign Up" button
3. Enter new user information (name, email, password)
4. Show password strength requirements feedback
5. Submit registration form
6. Demonstrate email verification process
7. Show successful account creation confirmation

**Expected Outcome:** *A new user account is created and accessible after email verification.*

**Key Points to Highlight:**
- GDPR compliance features
- Password strength requirements
- Email verification security
- User feedback during each step

**Potential Questions to Address:**
- How is user data stored securely?
- What happens if a user doesn't verify their email?
- Can users register using social accounts?

### 4.2 Scenario 2: User Login and Profile Management

**User Story Reference:** *US-102, US-104*

**Business Value:** *Provides secure access to authorized users and allows them to maintain accurate profile information.*

**Demonstrator:** *Jamie Jones*

**Demonstration Flow:**
1. Navigate to login page
2. Enter credentials for existing test user
3. Show successful login and dashboard access
4. Navigate to user profile section
5. Demonstrate editing profile information
6. Upload a profile picture
7. Save changes and show confirmation
8. Demonstrate logout functionality

**Expected Outcome:** *User can securely log in, update their profile information, and log out.*

**Key Points to Highlight:**
- Secure authentication process
- Profile data validation
- Image upload capability
- Session management

**Potential Questions to Address:**
- How are sessions managed for security?
- What profile information can users edit vs. what's fixed?
- Are there limitations on profile pictures?

### 4.3 Scenario 3: Password Reset Flow

**User Story Reference:** *US-103*

**Business Value:** *Reduces support calls by allowing users to securely recover access to their accounts without assistance.*

**Demonstrator:** *Riley Green*

**Demonstration Flow:**
1. Start at login page
2. Click "Forgot Password" link
3. Enter email address for password reset
4. Show email received with reset link
5. Click link and enter new password
6. Demonstrate password strength requirements
7. Show successful password change
8. Log in with new password

**Expected Outcome:** *User can successfully reset their password and regain access to their account.*

**Key Points to Highlight:**
- Security features of the reset process
- Time-limited reset tokens
- Email notifications for security

**Potential Questions to Address:**
- How long are reset links valid?
- What happens if a user doesn't receive the email?
- Are there limits on password reset attempts?

### 4.4 Scenario 4: Security Enhancements

**User Story Reference:** *TECH-015*

**Business Value:** *Protects user data and reduces security risks for the organization.*

**Demonstrator:** *Jamie Jones*

**Demonstration Flow:**
1. Brief overview of security enhancements implemented
2. Demonstrate rate limiting by showing too many failed login attempts
3. Show account lockout protection
4. Explain password hashing improvements (technical overview)

**Expected Outcome:** *Stakeholders understand the enhanced security measures protecting the system.*

**Key Points to Highlight:**
- Protection against brute force attacks
- Data protection improvements
- Compliance with security standards

**Potential Questions to Address:**
- How does this affect legitimate users?
- What security standards are we complying with?
- How do users get unlocked if locked out?

---

## 5. Stakeholder Feedback

### 5.1 Feedback Capture

*Record feedback from stakeholders during and after the demonstrations. Categorize feedback appropriately.*

| ID | Feedback | Source | Type | Priority | Related Feature |
|----|----------|--------|------|----------|----------------|
| *F-001* | *Password requirements should be more visible before user starts typing* | *Marketing Director* | *Improvement* | *Medium* | *User Registration* |
| *F-002* | *Users should be able to see when they were last logged in* | *Security Officer* | *New Feature* | *Low* | *User Login* |
| *F-003* | *The profile picture upload process is very intuitive* | *UX Designer* | *Positive* | *N/A* | *Profile Management* |
| *F-004* | *Would like to see support for two-factor authentication* | *Security Officer* | *New Feature* | *High* | *User Authentication* |
| *F-005* | *Reset password emails should have consistent branding with the main application* | *Marketing Director* | *Improvement* | *Low* | *Password Reset* |

### 5.2 Feedback Types

- **Positive Feedback**: Aspects that stakeholders particularly liked
- **Improvements**: Suggestions to enhance existing functionality
- **New Features**: Requests for new functionality
- **Concerns**: Worries or potential issues identified
- **Questions**: Items needing clarification or more information

### 5.3 Feedback Processing Approach

*Explain how the captured feedback will be processed.*

*Example: "All feedback items will be reviewed by the Product Owner and relevant team members within three business days. Improvement suggestions and new feature requests will be evaluated for business value and technical feasibility before being added to the Product Backlog. Concerns will be addressed with appropriate stakeholders directly. A summary of feedback processing will be shared before the next Sprint Planning meeting."*

---

## 6. Product Backlog Implications

### 6.1 New Backlog Items

*List new Product Backlog Items generated from the Sprint Review feedback.*

| ID | Type | Description | Initial Priority | Notes |
|----|------|-------------|-----------------|-------|
| *US-501* | *User Story* | *As a user, I want to see when I was last logged in so that I can verify my account security* | *Low* | *From feedback F-002* |
| *US-502* | *User Story* | *As a user, I want to enable two-factor authentication so that I can increase the security of my account* | *High* | *From feedback F-004, requires further research* |
| *IMP-101* | *Improvement* | *Make password requirements more visible before user starts typing* | *Medium* | *From feedback F-001, UX team to provide design* |
| *IMP-102* | *Improvement* | *Update reset password email templates to match application branding* | *Low* | *From feedback F-005* |

### 6.2 Backlog Refinement Needs

*Identify existing backlog items that need refinement based on Sprint Review insights.*

| ID | Description | Refinement Needed |
|----|-------------|-------------------|
| *US-105* | *As a user, I want to delete my account so that I can remove my data from the system* | *Need to consider implementation approach based on new GDPR compliance features* |
| *US-201* | *As a user, I want to see a dashboard when I log in so that I can access key information* | *Update to consider integration with last login information* |

### 6.3 Backlog Prioritization Changes

*Document any changes to backlog priorities based on Sprint Review feedback.*

| ID | Description | Old Priority | New Priority | Rationale |
|----|-------------|-------------|--------------|-----------|
| *US-301* | *As an admin, I want to manage user accounts so that I can help users with account issues* | *Medium* | *High* | *Security Officer emphasized importance after seeing authentication features* |
| *US-202* | *As a user, I want to customize my dashboard layout so that I can focus on relevant information* | *High* | *Medium* | *Authentication features deemed more critical for initial release* |

---

## 7. Release Planning Updates

### 7.1 Release Progress

**Current Release:** *R1.0 - Initial Customer Portal*

**Release Target Date:** *YYYY-MM-DD*

**Progress Summary:**
- *Sprint 5 of 8 completed*
- *25 of 54 story points completed (46%)*
- *3 of 7 epics completed*
- *On track / Slightly behind / Ahead of schedule*

### 7.2 Release Scope Updates

| Change | Description | Impact on Release |
|--------|-------------|-------------------|
| *Added* | *Two-factor authentication (based on feedback)* | *May require additional sprint, evaluating options* |
| *Removed* | *Advanced reporting features* | *Moved to future release to maintain focus on core functionality* |
| *Modified* | *User profile management* | *Expanded to include profile picture capabilities* |

### 7.3 Release Timeline Adjustments

| Milestone | Original Date | New Date | Reason for Change |
|-----------|---------------|----------|-------------------|
| *Beta Release* | *YYYY-MM-DD* | *YYYY-MM-DD* | *No change* |
| *Release Candidate* | *YYYY-MM-DD* | *YYYY-MM-DD* | *Delayed by 1 week to accommodate security enhancements* |
| *Production Release* | *YYYY-MM-DD* | *YYYY-MM-DD* | *Delayed by 1 week to maintain quality* |

### 7.4 Release Risks

| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| *Addition of two-factor authentication may delay release* | *Medium* | *High* | *Evaluating phased implementation approach* |
| *User documentation may not be complete in time* | *Low* | *Medium* | *Prioritizing core features documentation* |
| *Performance testing for full user load pending* | *Medium* | *Medium* | *Scheduled for next sprint* |

---

## 8. Key Metrics Review

### 8.1 Sprint Metrics

| Metric | Target | Actual | Trend | Comments |
|--------|--------|--------|-------|----------|
| *Velocity (Story Points)* | *25* | *23* | *↑* | *Improved over last sprint (20)* |
| *Scope Changes* | *0* | *1* | *↓* | *One feature added (password requirements display)* |
| *Bug Count (Found/Fixed)* | *<5/<5* | *3/3* | *→* | *All found bugs fixed* |
| *Testing Automation Coverage* | *85%* | *87%* | *↑* | *Exceeded target* |
| *Code Quality (Static Analysis)* | *A* | *A* | *→* | *Maintained code quality standard* |
| *Technical Debt* | *<10%* | *8%* | *↓* | *Reduced from 12% last sprint* |

### 8.2 Business Metrics

| Metric | Baseline | Current | Target | Comments |
|--------|----------|---------|--------|----------|
| *Development Cost per Story Point* | *$500* | *$480* | *$450* | *Improving efficiency* |
| *Lead Time (Idea to Implementation)* | *4 weeks* | *3.5 weeks* | *3 weeks* | *Improved refinement process* |
| *Requirements Stability* | *70%* | *85%* | *90%* | *Better requirements definition* |
| *Defect Density* | *0.5/SP* | *0.13/SP* | *<0.2/SP* | *Lower than target* |

### 8.3 Product Quality Metrics

| Quality Dimension | Measurement | Result | Target | Status |
|-------------------|-------------|--------|--------|--------|
| *Functional Suitability* | *User Acceptance Test Pass Rate* | *98%* | *>95%* | *Above Target* |
| *Performance Efficiency* | *Average Response Time* | *1.2s* | *<2s* | *Above Target* |
| *Compatibility* | *Browser/Device Test Pass Rate* | *95%* | *>90%* | *Above Target* |
| *Usability* | *User Error Rate* | *5%* | *<8%* | *Above Target* |
| *Security* | *Vulnerability Scan* | *2 low* | *0 high/medium* | *Meeting Target* |
| *Maintainability* | *Code Complexity Score* | *B+* | *B or higher* | *Meeting Target* |

### 8.4 Team Health Metrics

| Metric | Status | Trend | Comments |
|--------|--------|-------|----------|
| *Team Satisfaction* | *4.2/5* | *↑* | *Improved from 3.8 last sprint* |
| *Collaboration Level* | *Good* | *→* | *Consistent strong collaboration* |
| *Work-Life Balance* | *3.8/5* | *↓* | *Slightly down due to complex security implementation* |
| *Knowledge Sharing* | *4.0/5* | *↑* | *Regular tech talks implemented* |
| *Team Autonomy* | *4.5/5* | *→* | *Team making most decisions independently* |

---

## 9. Action Items

*Document specific actions resulting from the Sprint Review.*

| ID | Action Item | Owner | Due Date | Status | Priority | Category |
|----|------------|-------|----------|--------|----------|----------|
| *A-001* | *Evaluate two-factor authentication implementation options* | *Jamie Jones* | *YYYY-MM-DD* | *Not Started* | *High* | *Technical* |
| *A-002* | *Create mockups for password requirements visibility improvements* | *Casey Brown* | *YYYY-MM-DD* | *Not Started* | *Medium* | *UX Design* |
| *A-003* | *Update product backlog with new items from feedback* | *Jane Smith* | *YYYY-MM-DD* | *Not Started* | *High* | *Product Management* |
| *A-004* | *Schedule security review for authentication features* | *John Doe* | *YYYY-MM-DD* | *Not Started* | *High* | *Process* |
| *A-005* | *Create updated release timeline based on new priorities* | *Jane Smith* | *YYYY-MM-DD* | *Not Started* | *Medium* | *Planning* |
| *A-006* | *Follow up with Security Officer on two-factor requirements* | *John Doe* | *YYYY-MM-DD* | *Not Started* | *Medium* | *Stakeholder* |
| *A-007* | *Share sprint review outcomes with extended team* | *John Doe* | *YYYY-MM-DD* | *Not Started* | *Low* | *Communication* |

---

## 10. Next Steps

### 10.1 Immediate Next Steps

*Document the immediate next steps following the Sprint Review.*

1. **Product Backlog Refinement**
   - Product Owner to process feedback and update backlog (by *YYYY-MM-DD*)
   - Schedule refinement session to review new items (by *YYYY-MM-DD*)

2. **Action Item Follow-up**
   - Assign and track action items in the team's task management system
   - Scrum Master to follow up on high-priority items within 2 business days

3. **Sprint Retrospective Preparation**
   - Schedule Sprint Retrospective (on *YYYY-MM-DD*)
   - Share Sprint Review insights with the team ahead of retrospective

4. **Next Sprint Planning Preparation**
   - Update Sprint Planning agenda based on review outcomes
   - Product Owner to prepare top backlog items for next sprint

### 10.2 Process Improvements for Next Sprint Review

*Document any lessons learned about the Sprint Review process itself.*

- Allocate more time for demonstration of complex features
- Add a technical moderator role for handling demo environment issues
- Prepare more comprehensive backup demonstration options
- Schedule pre-review with key stakeholders for critical features

### 10.3 Timeline for Next Review and Demo

**Next Sprint:** *Sprint 6 (YYYY-MM-DD to YYYY-MM-DD)*  
**Next Sprint Review:** *YYYY-MM-DD, HH:MM - HH:MM*  
**Focus Areas for Next Demo:** *Dashboard functionality, reporting features, user administration*

---

## Appendix A: Sprint Review Checklist

```
SPRINT REVIEW PREPARATION CHECKLIST

Before the Review:
□ Sprint Review scheduled with appropriate attendees
□ Demonstration environment prepared and tested
□ Demo scenarios defined and documented
□ Roles assigned for the review meeting
□ Presentation materials (if any) prepared
□ Backup demonstration options ready
□ Sprint metrics compiled and analyzed
□ Demo dry run completed
□ Stakeholder-specific interests identified
□ Technical setup tested

During the Review:
□ Record attendance
□ Take notes on feedback
□ Document action items with owners
□ Capture stakeholder reactions
□ Track questions that need follow-up
□ Note any immediate product backlog implications

After the Review:
□ Document and distribute meeting minutes
□ Update Product Backlog based on feedback
□ Follow up on action items
□ Incorporate lessons learned
□ Update Release Plan if necessary
□ Communicate outcomes to wider team
□ Plan next steps
```

## Appendix B: Stakeholder Feedback Form

```
SPRINT REVIEW FEEDBACK FORM

Sprint: [Sprint Number]
Date: [YYYY-MM-DD]
Stakeholder Name: _________________________
Role/Department: _________________________

Please rate the following aspects of what you saw today (1-5 scale):
1. Functionality demonstrated: _____
2. Quality of the features: _____
3. User experience: _____
4. Alignment with business needs: _____
5. Value delivered: _____

What did you like most about what you saw today?
___________________________________________
___________________________________________

What concerns do you have about what you saw today?
___________________________________________
___________________________________________

What suggestions or improvement ideas do you have?
___________________________________________
___________________________________________

Any features you'd like to see prioritized in upcoming sprints?
___________________________________________
___________________________________________

Additional comments:
___________________________________________
___________________________________________

Thank you for your feedback!
```

## Appendix C: Common Demo Scenarios Template

```
DEMONSTRATION SCENARIO TEMPLATE

Scenario Name: [Name]
User Story Reference: [ID]
Business Value: [Description]
Demonstrator: [Name]

Pre-conditions:
- [List any pre-conditions or setup required]

Demonstration Steps:
1. [Step 1]
2. [Step 2]
3. [Step 3]
...

Expected Outcome:
[Describe what a successful demonstration looks like]

Key Points to Highlight:
- [Key point 1]
- [Key point 2]
- [Key point 3]

Potential Questions and Answers:
Q: [Anticipated question 1]
A: [Prepared answer 1]

Q: [Anticipated question 2]
A: [Prepared answer 2]

Fallback Plan:
[What to do if the demonstration doesn't work as expected]
```

---

*Note: This Sprint Review template aligns with Scrum Guide best practices. Teams should adapt it to their specific context and needs while maintaining the core principles of Scrum.*