Tips for Sprint Review in Scrum

🚨 A Hard Truth: A Sprint Review without stakeholders is a funeral rehearsal. Too often I observe: ❌ No stakeholders, just empty chairs. ❌ The wrong stakeholders, just warm bodies without influence. ❌ Stakeholders with no real "stake" in the product. ❌ Silent stakeholders who nod politely, mistaking attendance for engagement. When that happens, the event collapses into a "demo," a show and tell that checks a box instead of driving adaptation. The Sprint Review is not about "telling" stakeholders what you did. It is about asking them what they see and getting feedback on the latest Increment, even if we don't like the feedback. These are examples of questions we should be asking stakeholders: - Was the Sprint Goal achieved? - Does the Increment move us closer to the Product Goal? - What value was delivered, and what potential value is still missing? - Will this Increment actually make a difference for customers or the business? - What should we add, remove, refine, or reorder in the Product Backlog for upcoming Sprints? - What did we learn from customers, users, or market conditions? - Do we need to adjust forecasts, priorities, or plans? Ownership and practices that make the Sprint Review real: ✅ The Product Owner brings the right stakeholders to the table. ✅ The Scrum Master ensures everyone understands the purpose of the event. ✅ The Scrum Team makes it a collaboration, not a presentation. ✅ Stakeholders show up ready to engage, give feedback, and help steer direction. ✅ Ground the conversation in real data: metrics, trends, and forecasts. ✅ Include diverse perspectives from customers, users, business, and compliance. ✅ Keep the Increment usable and transparent so stakeholders can actually experience it. ✅ Ask open questions instead of delivering polished monologues. ✅ Focus not only on what was built, but on the impact delivered. ✅ Create psychological safety so feedback, even the tough kind, can be spoken and heard. A Sprint Review without feedback is not a review. It is a funeral rehearsal.

If your sprint reviews feel like status updates, you’re missing the point. Sprint reviews were never meant to be show-and-tell sessions. They’re meant to be decision points. But in many teams, that’s not what happens. Where most sprint reviews go wrong is that the review turns into a simple demo: ▪️Work is shown ▪️Stakeholders say “looks good” ▪️The meeting ends with no decisions The team presents. Stakeholders observe. Nothing actually changes. Over time, this leads to: ...wasted meetings ...disengaged stakeholders ...late feedback and rework ...features that get deprioritised later But here's what an effective sprint review should do A good review answers one question: 📍“Based on what we’ve seen, what changes next?” It’s not just about showcasing work but about shaping direction. Here's a simple structure that can help The 𝙍𝙚𝙫𝙞𝙚𝙬–𝙍𝙚𝙛𝙞𝙣𝙚–𝙍𝙚𝙖𝙡𝙞𝙜𝙣 𝙨𝙩𝙧𝙪𝙘𝙩𝙪𝙧𝙚 1️⃣ 𝙍𝙚𝙫𝙞𝙚𝙬 — What did we learn? Don’t just show the feature. Explain what the work revealed. →What assumption were we testing? →What did we discover? →Did anything change? 2️⃣ 𝙍𝙚𝙛𝙞𝙣𝙚 — What needs to change? Use the session to get real input. Ask: →What should we prioritise now? →What feels less important? →What would you adjust before the next sprint? The goal here isn’t agreement. It’s clarity. 3️⃣ 𝙍𝙚𝙖𝙡𝙞𝙜𝙣 — What happens next, and why? End the review by connecting decisions to outcomes. ❌️: “Next sprint we’ll work on notifications and settings.” ✅️: “Based on today’s feedback, we’re pausing notifications and focusing the next two sprints on search relevance. This supports our goal of reducing time to purchase.” One thing to always remember.... Sprint reviews aren’t about presenting work. They’re about deciding what comes next. And we should always ask - Does my sprint review drive decisions or just document progress? It’s Monday. A good day to rethink how our next review will actually move the work forward. Happy New Week. ----------- I appreciate everyone who showed up for Friday’s live session. Looking forward to seeing you at the next one. Follow Benjamina for practical perspectives on #projectexecution, #leadership judgment, and #delivery under real constraints.

You're Doing the Sprint Review All Wrong Too many teams misunderstand the purpose of the Sprint Review. For some, it becomes a one-way presentation where developers showcase the increment to the Product Owner. But here's the thing - if your PO is seeing the increment for the first time during the review, you've already gone off track. The Product Owner should be closely involved throughout the sprint, providing feedback and guidance daily, not waiting until the last day to catch up or speak up. Others treat the Sprint Review as a developer-led demo for stakeholders. They may even (wrongly) call the meeting a "Sprint Demo." While this approach is closer to the mark, it often becomes a passive session where stakeholders watch but don’t engage meaningfully. This approach misses an incredible opportunity. The Sprint Review is not just a showcase. It's supposed to be a collaborative feedback session with your stakeholders, including customers, users, and anyone else invested in the outcome. That's why the best and most fun and productive Sprint Reviews are interactive and hands-on. So, instead of developers running the show, put the deliverables in the hands of your stakeholders. Let them explore, interact with, and test the increment while the developers observe. This approach provides immediate, authentic feedback: Are the features intuitive? Do they solve the real problem? Are there unexpected pain points? By letting customers and stakeholders engage directly with the work, you’ll uncover insights you’d never get from a passive presentation. Plus, your team will build stronger relationships with the people who matter most. So stop treating the Sprint Review as a status update or developer showcase. Instead, make it a dynamic, customer-driven working session where feedback flows freely, and your team grows stronger and more aligned with stakeholder needs. That’s how you turn the Sprint Review into a true engine for continuous improvement.

“The Product Owner should never be surprised in the Sprint Review.” I took this advice to heart when a mentor gave it years ago. They pointed out the anti-pattern of a Product Owner who didn’t engage with the team and only saw the work done for the first time at the Sprint Review. Over the years, I have built on that advice, leading me to the meme of the day: “The PO does not simply walk into the Sprint Review.” The Sprint Review is the most critical event for the Product Owner. They own it, schedule it, set the agenda, and are generally the first and last to speak. When you own something, you don’t just show up and expect it to “happen.” It takes effort, focus, and time. Here are some tips I give Product Owners to make Sprint Reviews more effective:  ➡ Attend the Daily Scrum every day ➡ Review done work as soon as it’s done ➡ Don’t rely on the Invite alone ➡ Rehearse the day before ➡ Send out an agenda the day before Attend the Daily Scrum every day: Be available to answer questions and report progress towards the Sprint Goal. Remember, you are an observer; listen more than you speak. Review done work as soon as it’s done: When an item is done, sit down with the developers as quickly as possible to review it. The sooner you review it, the sooner adjustments can be made if it doesn’t hit the mark. Don’t rely on the Invite alone: You’ve been triple booked before, and your stakeholders are no different. If they decide to attend solely on the calendar invite, they may end up in another meeting. Call them, text them, or show up at their office (unless their office is in their basement). Rehearse the day before: Before a play launches, they do at least one complete run-through of the whole play. Get together with the developers, review what work is done, and then ensure all the technical bits and bobs are working to demonstrate the work done. You don’t want to scramble with tech in front of your stakeholders. Send out an agenda the day before: After you rehearse, you know exactly what you will demonstrate. Use that to craft your agenda and send it to your stakeholders. It will help them to decide if they are going to attend (tying right back to “Don’t rely on the invite alone.”) A general facilitation guideline is to spend at least the same time preparing for an event as the event timebox. For a two-week Sprint, the Sprint Review is generally two hours. Between attending Daily Scrums, the rehearsal, and one-on-one reviews of completed items, you can easily spend more than two hours ensuring your Sprint Reviews are valuable meetings. How much time are you spending preparing for your next Sprint Review? This has been a 🦍 Gorilla Coach 🦍 Scrumdamentals moment. Have a nice day. #Agile #Scrum #Sustainability #ContinuousImprovement #SustainableValue  #DoBetterScrum

Getting stakeholders to show up and stay engaged during Sprint Reviews can be a real challenge. But the Sprint Review is more than just a demo; it's your chance to gather feedback, validate direction, and build trust. If your reviews feel more like a monologue than a collaboration, Here are 8 practical ways to change that: Choose the Right Time & Day ↳ Avoid Monday mornings and peak meeting times. ↳ A time change alone can boost attendance and energy. Keep It Engaging ↳ Focus on high-impact features, not every minor bug fix. ↳ Only show low-priority items if stakeholders ask. Control the Discussion Flow ↳ Keep conversations focused and on-topic. ↳ Redirect deep dives to follow-up discussions outside the review. Let Stakeholders Participate Actively ↳ Invite them to test new features live during the review. ↳ This boosts ownership, engagement, and trust. Communicate the Purpose Clearly ↳ Share an agenda a day before the review. ↳ Outline Sprint goals, key demos, and decisions needed. Respect Stakeholders’ Time ↳ Not all stakeholders need to attend every review. ↳ Let them know when their input is optional. Encourage Conversations, Not Just Presentations ↳ Ask for feedback right after showcasing a feature. ↳ Engage senior stakeholders first to encourage others to speak up. Show That Feedback Matters ↳ Implement valuable suggestions quickly. ↳ Highlight changes based on past stakeholder feedback. When Sprint Reviews become interactive, focused, and valuable, stakeholders stop skipping them and start looking forward to them. What’s one thing you’ve done that actually got your stakeholders more involved in Sprint Reviews? Drop your experience or tip in the comments. ♻️ Repost to help others standout in their agile journey. ➕ Follow Dr. Francis Mbunya for more.