Agile-and-Scrum **Sprint Review – Stakeholder Feedback on Increment**

Sprint Review – Stakeholder Feedback on Increment

Hyper-Practical Study Guide for Agile & Scrum (Scrum Guide 2020)

1. What This Is & Why It Matters

The Sprint Review is your team’s live product demo + feedback loop—not a status report, not a PowerPoint, and definitely not a post-mortem. It’s the only Scrum event where stakeholders (customers, PMs, executives) get to see, touch, and critique the actual working software you built in the last Sprint.

Why it matters in production:
- If you skip it or turn it into a "show and tell," stakeholders assume you’re building the wrong thing—then they micromanage, demand last-minute changes, or (worst case) cancel the project.
- If you do it right, you get real-time course correction—like a GPS rerouting you before you drive off a cliff. Example: You demo a new checkout flow, and the product owner says, "Wait, we need Apple Pay support by next Sprint." Now you adjust before wasting two weeks on the wrong feature.

Real-world scenario:
You’re a Scrum Team building a SaaS analytics dashboard. The CEO attends the Sprint Review, sees the new "user retention" chart, and says, "This is great, but we need to compare it to last quarter’s data." Without this feedback, your team would’ve spent the next Sprint polishing a feature that doesn’t solve the business problem.

2. Core Concepts & Components

3. Step-by-Step: Running a Sprint Review (Like a Pro)

Prerequisites

✅ You have a Done Increment (no "90% done").
✅ Stakeholders are invited (send calendar invites at least 3 days in advance).
✅ You have a demo environment (staging, feature flags, or local setup).
✅ The Product Owner (PO) is prepared to prioritize feedback.

Step 1: Set the Stage (5 min)

• Goal: Align everyone on what’s being demoed and why it matters.
• Script:

  "Today, we’ll show the new ‘user retention’ dashboard. This helps marketing track which campaigns drive repeat purchases. After the demo, we’ll discuss what’s next. Questions?"

  
  

• Pro Tip: Start with the "why"—stakeholders care about business impact, not technical details.

Step 2: Demo the Increment (15–30 min)

• Rule: Show, don’t tell. No slides—just the working software.
• Structure:
• What was the Sprint Goal? (1 sentence)
• What did we build? (Walk through the Increment)
• What didn’t we build? (Be transparent—stakeholders appreciate honesty)
• Example Demo Script (Analytics Dashboard):
  ```markdown
• Sprint Goal: "Enable marketing to track user retention by campaign."
• What we built:
  • New "Retention" tab in the dashboard.
  • Filters for date range, campaign, and user segment.
  • Export to CSV.
• What we didn’t build:
  • Comparison to last quarter (we’ll add this next Sprint).
  • Mobile view (coming in 2 Sprints).
    ```
• Pro Tip: Record the demo (Loom, Zoom) for stakeholders who can’t attend.

Step 3: Gather Feedback (20–30 min)

• Goal: Uncover misalignments before they become expensive problems.
• Techniques:
• Open-Ended Questions:
  • "What’s one thing that surprised you?"
  • "What’s missing that would make this 10x more useful?"
• Silent Brainstorming:
  • Give stakeholders 2 minutes to write down feedback before discussing.
• Dot Voting:
  • Write feedback on sticky notes, let stakeholders vote on top priorities.
• Pro Tip: Avoid defensiveness. If a stakeholder says, "This is useless," ask: "What would make it useful?"

Step 4: Update the Product Backlog (10–15 min)

• Goal: Translate feedback into actionable backlog items.
• How:
• PO reviews feedback and decides what to prioritize.
• Team estimates new items (if needed).
• Update the backlog (Jira, Trello, etc.) during the meeting.

• Example:
  | Feedback | Backlog Item | Priority | |----------|--------------|----------| | "Need last quarter’s data" | Add "Compare to Previous Period" toggle | High | | "Export is slow" | Optimize CSV export query | Medium | | "Mobile view is critical" | Build responsive design | High |

• Pro Tip: Assign an owner to each new item (e.g., "Dev Team, can you estimate this by EOD?").

Step 5: Close with Next Steps (5 min)

• Goal: Ensure everyone leaves aligned.
• Script:

  "Based on today’s feedback, we’ll: 1. Add ‘Compare to Previous Period’ next Sprint.
  2. Optimize the CSV export.
  3. Start mobile design.
  Any objections?"

  
  

• Pro Tip: Send a follow-up email with:
• Recording of the demo.
• Updated backlog.
• Next Sprint’s focus.

4. ? Production-Ready Best Practices

? Security & Compliance

• Never demo on production. Use staging, feature flags, or mock data.
• Mask sensitive data (e.g., PII, API keys) in demos.
• Record demos (with permission) for compliance/audit trails.

? Cost Optimization

• Use ephemeral environments (e.g., AWS CloudFormation, Terraform) to spin up/down demo setups.
• Avoid "demo-only" infrastructure—reuse staging environments.

?️ Reliability & Maintainability

• Automate demos (e.g., Selenium scripts, Postman collections) to reduce manual prep time.
• Version control your demo scripts (e.g., GitHub) so anyone can run them.
• Tag demo environments (e.g., env:demo) for easy cleanup.

?️ Observability

• Monitor demo environments (e.g., Datadog, New Relic) to catch issues before the Review.
• Log demo sessions (e.g., "Sprint 12 Review – 2024-05-20") for future reference.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Who attends the Sprint Review?"
2. ✅ Correct: Dev Team, PO, Scrum Master, stakeholders.

3. ❌ Trap: "Only the Scrum Team" (forgets stakeholders).

4. "What’s the main output of the Sprint Review?"

5. ✅ Correct: An updated Product Backlog.

6. ❌ Trap: "A demo" (demo is a means, not the output).

7. "What if the Increment isn’t Done?"

8. ✅ Correct: Don’t demo it. Discuss why and adjust the Definition of Done.

9. ❌ Trap: "Demo it anyway" (violates Scrum principles).

10. "How long should a Sprint Review be for a 2-week Sprint?"

11. ✅ Correct: Max 2 hours (1 hour per week of Sprint).
12. ❌ Trap: "4 hours" (that’s for a 4-week Sprint).

Key Distinctions

• Sprint Review vs. Sprint Retrospective:
• Review: Focuses on the product (what was built).
• Retrospective: Focuses on the process (how we built it).
• Stakeholder Feedback vs. Approval:
• Feedback: Collaborative input.
• Approval: Waterfall gate (not Agile).

7. ? Hands-On Challenge

Challenge:
You’re the Scrum Master for a team building a mobile banking app. The PO wants to demo a new "budgeting" feature in the Sprint Review, but the Dev Team says it’s "90% done" (missing error handling and UI polish). What do you do?

Solution:
1. Don’t demo it. "90% done" = not Done.
2. Demo what is Done (e.g., the backend API, a mockup).
3. Explain the gap transparently:

"We built the core budgeting logic, but we’re still polishing the UI and error handling. We’ll show the full feature next Sprint." 4. Update the backlog to reflect the remaining work.

Why it works:
- Maintains trust (no fake demos).
- Sets realistic expectations (stakeholders know what’s coming).
- Keeps the team accountable (no "almost done" excuses).

8. ? Rapid-Reference Crib Sheet

9. ? Where to Go Next

1. Scrum Guide 2020 – Sprint Review (Official definition)
2. Atlassian – Sprint Review Best Practices (Practical tips)
3. Scrum.org – Sprint Review vs. Retrospective (Key distinctions)
4. Roman Pichler – Stakeholder Management (How to engage stakeholders effectively)