Sprint review
The sprint review is a ceremony held at the end of each sprint where the Scrum Team and stakeholders inspect the work completed during the sprint and adapt the product backlog based on feedback. It's a collaborative working session, not a formal presentation or status report. The sprint review connects what was built to what should be built next, maintaining alignment between development and stakeholder expectations.
Why it matters
Sprint reviews create regular touchpoints between builders and stakeholders. They provide transparency so stakeholders see actual progress, not just updates. They create a feedback loop where reactions inform future direction. They maintain alignment so expectations stay synchronized. They enable adaptation as plans adjust based on reality. They establish accountability because teams deliver something reviewable every sprint. And they build trust through regular visibility that creates confidence.
Without sprint reviews, development can drift from stakeholder needs, and problems compound before they're discovered.
Sprint review vs. sprint demo
The terms overlap but aren't identical. Sprint demo emphasizes the demonstration of completed work - the "show and tell" portion. Sprint review is broader - it includes the demo, but also discussion, feedback, and collaborative planning. It's a working session, not a presentation.
In practice, the demo is often the centerpiece of the sprint review, but the valuable conversation around it is equally important.
Sprint review structure
Time box is based on sprint length. A 1-week sprint allows 1 hour maximum. A 2-week sprint allows 2 hours maximum. A 4-week sprint allows 4 hours maximum.
Participants include required attendees (Product Owner, Development Team, Scrum Master), important attendees (key stakeholders, subject matter experts, users when possible), and optional attendees (other teams, leadership, customers).
Typical flow begins with an opening (5-10 minutes) providing welcome and context, sprint goal reminder, and summary of what was planned. Demonstration (30-60 minutes) shows completed work as working software rather than presentations, using user-focused scenarios with questions encouraged. Discussion (15-30 minutes) captures stakeholder feedback, questions and clarifications, ideas and suggestions, and concerns and risks. Backlog review (10-20 minutes) covers current state of the product backlog, how feedback affects priorities, what might come next, and timeline and roadmap context. Closing (5 minutes) summarizes feedback, outlines next steps, and notes upcoming milestones.
Effective sprint reviews
Show working software because the sprint review inspects the increment - actual working software that could potentially be released. Avoid slide presentations instead of demos, mockups or prototypes (unless that's the deliverable), promised future functionality, and technical details irrelevant to stakeholders.
Create dialogue because sprint reviews are conversations, not performances. Pause for questions during demos, ask stakeholders for reactions, explore concerns and ideas, and make it interactive.
Focus on value by connecting demonstrations to user and business value. "This helps customers because..." "The business impact is..." "Users told us they needed..." Avoid pure technical descriptions without value context.
Capture feedback by designating someone to capture specific feedback on demonstrated features, new ideas and suggestions, questions requiring follow-up, and concerns to address. Feedback without capture is feedback lost.
Keep it honest so sprint reviews are truthful. Show what was actually completed, acknowledge what wasn't finished, be honest about challenges, and don't hide problems. Trust requires honesty.
What to review
Completed work includes items that meet the Definition of Done - features demonstrated end-to-end, bug fixes (briefly, if impactful), user experience improvements, and technical improvements with user impact.
Sprint goal achievement answers whether the team achieved the sprint goal. If yes, demonstrate how. If partially, explain what was achieved. If no, explain what happened.
Metrics and data when relevant include usage data for previous features, feedback from customers, quality metrics, and business outcomes.
Context updates include information that affects future planning - market changes, customer developments, technical discoveries, and organizational updates.
Stakeholder engagement
Preparing stakeholders helps them participate effectively by sharing the agenda in advance, explaining what to expect, clarifying what feedback is helpful, and setting expectations about decisions.
Encouraging participation engages stakeholders by asking specific questions, creating space for different perspectives, following up on their previous feedback, and showing how their input influenced development.
Managing difficult feedback requires listening without defensiveness, asking clarifying questions, acknowledging concerns, explaining trade-offs when relevant, and committing to follow-up where appropriate.
Attendance problems when stakeholders don't attend require making sessions valuable enough to prioritize, adjusting timing to their schedules, providing alternative formats (recordings, summaries), and having direct conversations about importance.
After the sprint review
Process feedback by reviewing captured feedback as a team. What actions are needed? What goes into the backlog? What needs further discussion? What was just commentary?
Update backlog to reflect feedback through new items based on feedback, adjusted priorities, refined existing items, and removed invalidated items.
Communicate outcomes to those who couldn't attend through a summary of what was demonstrated, key feedback received, impact on upcoming work, and recording if available.
Sprint review anti-patterns
Presentation theater uses polished presentations that hide reality. Real sprint reviews show real software, including rough edges.
Stakeholder absence means reviews that only the Scrum Team attends. Without stakeholders, there's no external feedback and no alignment.
One-way communication treats the demo as a performance with no dialogue. Reviews should be interactive conversations.
Status report format reviews activities instead of outcomes. Focus on what was built, not what people did.
Demo-only session skips the discussion and planning portions. The demo is important, but the conversation around it is equally valuable.
Sprint review and product management
Product managers play key roles in sprint reviews by framing work in strategic context, facilitating stakeholder feedback, connecting demonstrations to customer needs, using feedback to inform backlog decisions, and communicating outcomes to the broader organization.
Tools like Klero help by connecting sprint work to customer feedback. When stakeholders can see how features address real user requests, reviews become more compelling. When feedback from reviews flows into the same system as customer feedback, product decisions become more informed and traceable.
