Sprint Review Meeting Template: Agenda, Demo Script & Stakeholder Questions

Sprint Review Meeting Template

Purpose: Inspect the increment and adapt the product backlog based on stakeholder feedback.

Attendees: Development team, Scrum Master, Product Owner, key stakeholders

Duration: 60-90 minutes (1 hour per 2-week sprint is a good rule of thumb)

---

Pre-Meeting Checklist (Product Owner)

Complete 24 hours before the sprint review:

• [ ] Confirm which stories meet Definition of Done
• [ ] Prepare demo environment (staging, not localhost)
• [ ] Share sprint goal with stakeholders in advance
• [ ] Send calendar invite with agenda attached
• [ ] Prepare list of stories NOT completed (with reason)
• [ ] Collect any bugs found during sprint for disclosure
• [ ] Prepare updated backlog for discussion

---

Sprint Review Agenda

1. Sprint Summary (5-10 min)

Facilitator (Product Owner):

Sprint: [Sprint #] | [Start Date] – [End Date]
Sprint Goal: [Your sprint goal here]
Team: [Team name]
Velocity: [Planned points] planned, [Completed points] delivered

What to cover:

• Sprint goal: Was it achieved? Yes / Partially / No
• Total points planned vs. delivered
• Stories completed vs. stories not completed
• Any major blockers or issues encountered

Example opening:

"Welcome to Sprint 12's review. Our goal this sprint was to complete the checkout flow redesign. I'm happy to report we achieved our sprint goal — here's what we built."

---

2. Demo of Completed Work (30-45 min)

For each completed user story, follow this script:

Story Demo Script

Story: [Story title and Jira ticket ID]
────────────────────────────────────────
As a reminder: [Read the user story]

What we built:
[Developer or PO walks through the feature in staging]

How to test it:
[Show step-by-step: what to click, what to see]

Acceptance criteria:
✅ [Criteria 1]
✅ [Criteria 2]
✅ [Criteria 3]

Edge cases handled:
- [Any special cases you want to highlight]

Demo order (recommended):

1. High-value customer-facing features first
2. Infrastructure/backend improvements second
3. Bug fixes last

Demo tips:

• Use real data, not "lorem ipsum"
• Show the user journey end-to-end
• Have a backup (screenshots or video) if live demo fails
• Assign one person per feature to demo

---

3. Stories Not Completed (5-10 min)

For each story NOT delivered:

Story: [Story title]
────────────────────────
Reason not completed:
  ☐ Scope expanded during sprint
  ☐ Technical blocker
  ☐ Dependency on external team
  ☐ Underestimated complexity
  ☐ Priority changed mid-sprint
  ☐ Other: ______________

Plan:
  ☐ Carry over to next sprint
  ☐ Re-estimate and re-prioritize
  ☐ Descope or break into smaller pieces
  ☐ Assign to different team

---

4. Stakeholder Q&A and Feedback (15-20 min)

Opening prompt from PO:

"We'd love your feedback. Does this meet your expectations? Is anything missing or confusing? What should we prioritize next?"

Guiding questions for stakeholders:

Discovery questions:
- Does this feature solve your problem?
- What would make this 10x more useful?
- Is there anything you expected to see but didn't?

Validation questions:
- Does this meet the acceptance criteria we discussed?
- Is the UX intuitive? Where did you get confused?
- Does this integrate well with your workflow?

Priority questions:
- Given what you've seen, what should we focus on next?
- Are there any upcoming events that should change our priorities?
- What would you demo to your stakeholders from this sprint?

Capture all feedback:

| Feedback | From | Priority | Action | |----------|------|----------|--------| | [Feedback] | [Name] | High/Med/Low | Add to backlog / Fix now / Defer | | | | | | | | | | |

---

5. Backlog Discussion (10-15 min)

Product Owner leads:

Upcoming sprint candidates:
1. [Story title] — [priority reason]
2. [Story title] — [priority reason]
3. [Story title] — [priority reason]

Items being removed or deferred:
- [Story title] — [reason]

New items added based on today's feedback:
- [Story title] — [description]

Questions to ask stakeholders:

• "Given today's feedback, should we reprioritize anything?"
• "Are these the right stories for next sprint?"
• "Any new information that changes what we should build?"

---

6. Wrap-Up (5 min)

Action items from sprint review:

| Action | Owner | Due Date | |--------|-------|----------| | | | | | | | |

Next sprint preview:

• Sprint dates: [Start] – [End]
• Sprint planning: [Date and time]
• Tentative sprint goal: [Draft goal]

---

Sprint Review Meeting Notes Template

Date: [Date]
Sprint: [Number]
Attendees: [List]

SPRINT GOAL: [Goal]
STATUS: ✅ Achieved / ⚠️ Partially Achieved / ❌ Not Achieved

COMPLETED STORIES:
✅ [Story 1] — [Points]
✅ [Story 2] — [Points]
✅ [Story 3] — [Points]

NOT COMPLETED:
❌ [Story] — Reason: [Reason] → Will [carry over / re-scope]

DEMO FEEDBACK:
- [Stakeholder]: [Feedback]
- [Stakeholder]: [Feedback]

NEW BACKLOG ITEMS (from feedback):
- [Item 1]
- [Item 2]

BACKLOG REPRIORITIZATION:
- [Story] moved up/down because [reason]

ACTION ITEMS:
- [Action] → [Owner] → [Due date]

NEXT SPRINT:
- Goal: [Draft goal]
- Sprint planning: [Date]

---

Sprint Review vs Sprint Retrospective

Teams often confuse these. Key differences:

| Aspect | Sprint Review | Sprint Retrospective | |--------|---------------|---------------------| | Focus | Product and what was built | Team process and how we work | | Attendees | Team + stakeholders | Team only (sometimes Scrum Master only) | | Output | Updated product backlog | Improvement action items | | Question | "Did we build the right thing?" | "Did we build it the right way?" | | Timing | End of sprint, before retro | After review, end of sprint | | Duration | 60-90 min | 60-90 min |

Both are required in Scrum. Don't skip either.

---

Definition of Done Checklist (for Demo)

Before demoing any story, confirm:

• [ ] Code reviewed and approved (2 reviewers)
• [ ] All tests passing (unit, integration)
• [ ] No critical or high bugs introduced
• [ ] Deployed to staging environment
• [ ] Acceptance criteria verified by PO
• [ ] Documentation updated (API docs, README)
• [ ] Performance tested (no regression)
• [ ] Accessibility checked (WCAG 2.1 AA)
• [ ] Product Owner formally accepts the story

If any box is unchecked, the story cannot be demoed as "Done."

---

Remote Sprint Review Tips

If running the review remotely:

1. Use screen share for demos — developer shares their staging screen
2. Record the meeting — share with stakeholders who couldn't attend
3. Live polling — use Mentimeter or Slido for stakeholder prioritization
4. Chat for feedback — encourage stakeholders to type questions in chat during demos
5. Virtual whiteboard — Miro or FigJam for backlog prioritization discussion

---

Common Sprint Review Mistakes

| Mistake | Impact | Fix | |---------|--------|-----| | Demoing incomplete work | Wastes stakeholder time | Only demo stories that meet DoD | | No stakeholders attend | No feedback loop | Make attendance mandatory; record and send recap | | Skipping for "small sprints" | Missed learning | Always run it, shorten if needed | | Mixing review and retro | Confusion, no clear action | Keep them separate | | No follow-up on feedback | Stakeholders disengage | Create Jira tickets for all feedback | | Demo on localhost | Demo fails in prod | Always use staging environment |