Optimizing Sprint Reviews

I've sat through 100s of Sprint Reviews. Most of them were painful. Why? • Too much detail • No clear structure • Everyone lost in the weeds Until I discovered this simple truth: Great Sprint Reviews aren't meetings. They're stories. And here's how you can tell yours: Chapter 1: The Players → Names → Roles → Location (if distributed) Chapter 2: The Quest → Share your Sprint Goal → Be honest about success or failure → Describe the pivots (they always happen) Chapter 3: The Journey → Strategy we chose → Battles we fought → Treasures we discovered → Value we delivered Chapter 4: The Heroes → Celebrate individual achievements → Acknowledge helping hands → Own collective failures Chapter 5: The Proof → Show working software → Minimal PowerPoints → Real value, real demo Chapter 6: The Feedback → Capture reactions → Document insights → Build confidence Chapter 7: The Next Adventure → Set next review date → Preview coming challenges → Thank your audience And Remember: → Product Owner narrates the story → Scrum Master ensures it's heard Stop running reviews like status updates. Start telling your sprint's story. Because great products are not built in spreadsheets. They're built through stories that connect, inspire, and drive action. 👋 #agile #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.

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.

‼️ Why the Sprint Review is the Most Important Scrum Event - also for Scrum Masters: Last week, I asked my LinkedIn network: "What would YOU 🫵🏻 say is THE MOST IMPORTANT Scrum event for Scrum Masters?" 👉🏻 68% answered "The Sprint Retrospective". This answer did not surprise me. I can understand that many instinctively point to the Sprint Retrospective. And they’re not wrong. After all, the Retrospective is where the team pauses, reflects, and improves. It’s the heartbeat of continuous improvement, and without it, a Scrum Team stagnates. 🚨But here's the thing: even the most effective Retrospective won’t matter if the team isn’t getting fast, meaningful feedback on the product itself. The Sprint Review is where the magic 🧚♀️ happens—or at least, where it should happen. It’s not just a "demo." It’s the moment when the team steps back and asks: ⭐️ Are we delivering value to the customer? ⭐️ Are we solving their problems effectively? ⭐️ Are we on the right track, or do we need to pivot? It’s where stakeholders, customers, and the Scrum Team come together to inspect and adapt the product itself. When this event lacks collaboration or is treated as a formality, something critical is lost: the feedback loop that keeps us aligned with real-world needs. (Be honest: how many of your Sprint Reviews had no stakeholders/customers/users at all?) In a world of complexity and constant change, feedback is gold. If it’s delayed, rare, or superficial, we risk heading in the wrong direction—and no amount of reflection in a Retrospective will fix that. Here’s why the Sprint Review truly matters: ✅ It keeps us focused on the customer. Without hearing from stakeholders or users, we’re flying blind. The Sprint Review ensures their voices are part of the process. ✅ It fosters accountability and alignment. Regular, engaged conversations about the product ensure that everyone—from developers to stakeholders—is working toward the same goals. ✅ It enables faster learning. The sooner we hear what's working (or not), the faster we can adapt and deliver better value. So yes, the Sprint Retrospective is crucial—it sharpens the team and its collaboration, but the Sprint Review sharpens the product. If your Sprint Reviews lack energy or aren’t happening effectively, ask yourself: 👉 Are the right stakeholders attending? 👉 Are the stakeholders and end-users genuinely engaged? 👉 Are we showcasing value or just ticking off completed tasks? 👉 Are we inviting feedback, not just applause? Remember: Scrum thrives on fast feedback. Without it, we’re just iterating for iteration’s sake. Let’s make the Sprint Review the lively, inspiring, and essential event it’s meant to be. ❓❓ What’s your take? How do you energize Sprint Reviews? 🚀 #ScrumMastery #AgileMindset #SprintReview #ContinuousImprovement

I’ll be sharing a few lessons from challenges we’ve faced at Cafeto and how we’ve addressed them. On this occasion, I want to talk about our experience adopting PHVA (Plan Do Check Act) in our Agile development process. Because we primarily build for customers, service quality and predictability matter a lot, so optimizing how we work is core to delivering better outcomes. As we adopted PHVA, our process became lighter, clearer, and more consistent across projects, helping teams move faster while improving quality. For small and mid size projects, this structure has been especially effective because planning stays lightweight while design and QA get dedicated runway. We typically run two week sprints with UX and Architecture one sprint ahead and QA in a parallel hardening sprint. We also noticed a common anti pattern where planning defaults to coding, leaving design and testing squeezed. We address this by giving each phase its own lane and cadence: Plan (Design first): Plan is not a coding meeting. We emphasize design and discovery, user flows, states, accessibility, API contracts, and clear acceptance criteria. UX and architecture run one sprint ahead, so delivery starts with clarity. For small and mid projects, we keep slices to about 1 to 2 weeks of effort and limit WIP. Do (Build and Reviews): Implement the slice incrementally with feature flags as guardrails, conduct code reviews as part of the work, pair on complex pieces, keep PRs small, write test cases, and maintain steady flow. Check (Validate and Test): Ensure the increment is properly validated with testing suites for functional and non functional checks such as performance, security, and accessibility. QA works a parallel sprint, hardening the increment to be delivered and preparing test assets for what is next. Act (User Acceptance): Secure customer blessing on the delivered increment through UAT. Capture feedback, update the backlog, and roll learnings into the next Plan phase. Working this way has meant fewer handoffs, cleaner releases, and faster feedback loops, which adds up to better results for customers. Not perfection, just steady improvements that compound every sprint. On larger programs, we scale the same loop across multiple teams, and the fundamentals do not change. #Agile #DevOps #QA #UX #ContinuousImprovement #PHVA #PDCA #Cafeto #Product #Delivery #CustomerExperience #Nearshoring

I've lost count of how many ineffective sprint reviews I've attended over the years. Often, the meetings focused on justifying the progress made by the team and collecting new stakeholder requests. To help you avoid meetings like this and get the most out of your sprint reviews, I've recorded a new 📽️ YouTube video. In the video, I share the following six tips to fully leverage sprint review meetings as the person in charge of the product: 🎯 𝗕𝗲 𝗖𝗹𝗲𝗮𝗿 𝗼𝗻 𝘁𝗵𝗲 𝗠𝗲𝗲𝘁𝗶𝗻𝗴 𝗢𝗯𝗷𝗲𝗰𝘁𝗶𝘃𝗲𝘀: Use the meeting not only to track product delivery but also to facilitate 𝘱𝘳𝘰𝘥𝘶𝘤𝘵 𝘥𝘪𝘴𝘤𝘰𝘷𝘦𝘳𝘺. 🧡 𝗜𝗻𝘃𝗼𝗹𝘃𝗲 𝘁𝗵𝗲 𝗥𝗶𝗴𝗵𝘁 𝗣𝗲𝗼𝗽𝗹𝗲: Collect feedback from users, customers, and business stakeholders to maximise the chances of offering a successful product. ✂️ 𝗦𝗽𝗹𝗶𝘁 𝘁𝗵𝗲 𝗠𝗲𝗲𝘁𝗶𝗻𝗴 𝗶𝗻𝘁𝗼 𝗧𝘄𝗼 𝗪𝗵𝗲𝗻 𝗡𝗲𝗲𝗱𝗲𝗱: Consider having a meeting with the development team(s) first and then opening it up to the stakeholders. 💡 𝗘𝗻𝗰𝗼𝘂𝗿𝗮𝗴𝗲 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗯𝘂𝘁 𝗗𝗼𝗻’𝘁 𝗦𝗮𝘆 𝗬𝗲𝘀 𝘁𝗼 𝗘𝘃𝗲𝗿𝘆 𝗜𝗱𝗲𝗮: Use the product strategy and the product goal you've set to determine how to respond to suggestions and requests. 📈 𝗧𝗿𝗮𝗰𝗸 𝘁𝗵𝗲 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗣𝗿𝗼𝗴𝗿𝗲𝘀𝘀 to balance meeting the product goal with delivering on time and on budget. 📦 𝗖𝗼𝗻𝘀𝗶𝗱𝗲𝗿 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗶𝗻𝗴 𝗨𝘀𝗲𝗿 𝗮𝗻𝗱 𝗦𝘁𝗮𝗸𝗲𝗵𝗼𝗹𝗱𝗲𝗿 𝗙𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗦𝗲𝗽𝗮𝗿𝗮𝘁𝗲𝗹𝘆: Use a product demo to gather the views of the business stakeholders, and employ usability tests and early releases to collect feedback from users and customers. Hope you'll find the video helpful! Let me know your sprint review questions and experiences in the comments. https://lnkd.in/exDArCn6 #productmanagement #productdiscovery #sprintreview #scrum #agile

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.

I just saw what I think is the most productive sprint review I've ever witnessed. It wasn't due to the demonstration of the product. It was the 40 minutes of *transparent and honest discussion* between business stakeholders and the development teams. Far too often, a sprint review is treated like a demo. A one-way exercise. Those are a waste of time. Development teams frequently work their butts off only to discover months later they were off track. Leaders often attend "demos" at the end of each sprint, but no one asks them what they think, and they're too polite to speak up when things are looking like they're moving in the wrong direction. (And worse, they stop attending because they don't feel like they're contributing.) Healthy sprint reviews are a collaborative event, with clear and transparent communication not only between stakeholders and the development teams, but also among stakeholders themselves. Neither stakeholders nor dev teams can work in isolation. Only when everyone is pushing in the same direction can they accomplish great things. And the foundation of that is clear, honest, and open communication.

Frustrated with your Sprint Reviews? Here’s why they might be a waste of time and how to fix it: Too often, Sprint Reviews become dull status updates. But they should be dynamic sessions focused on the product and its improvement. Here’s a 5-step approach to transform your Sprint Reviews: 🎯 𝐅𝐨𝐜𝐮𝐬 𝐨𝐧 𝐭𝐡𝐞 𝐏𝐫𝐨𝐝𝐮𝐜𝐭: 𝘋𝘪𝘴𝘤𝘶𝘴𝘴 𝘵𝘩𝘦 𝘱𝘳𝘰𝘥𝘶𝘤𝘵'𝘴 𝘷𝘢𝘭𝘶𝘦, 𝘯𝘰𝘵 𝘫𝘶𝘴𝘵 𝘤𝘰𝘮𝘱𝘭𝘦𝘵𝘦𝘥 𝘵𝘢𝘴𝘬𝘴. 🤝🏻 𝐄𝐧𝐠𝐚𝐠𝐞 𝐒𝐭𝐚𝐤𝐞𝐡𝐨𝐥𝐝𝐞𝐫𝐬: 𝘐𝘯𝘷𝘪𝘵𝘦 𝘧𝘦𝘦𝘥𝘣𝘢𝘤𝘬 𝘧𝘳𝘰𝘮 𝘢𝘭𝘭 𝘴𝘵𝘢𝘬𝘦𝘩𝘰𝘭𝘥𝘦𝘳𝘴. 🎥 𝐒𝐡𝐨𝐰, 𝐃𝐨𝐧’𝐭 𝐓𝐞𝐥𝐥: 𝘋𝘦𝘮𝘰𝘯𝘴𝘵𝘳𝘢𝘵𝘦 𝘵𝘩𝘦 𝘱𝘳𝘰𝘥𝘶𝘤𝘵. 𝘓𝘦𝘵 𝘪𝘵 𝘴𝘱𝘦𝘢𝘬. 🗣 𝐄𝐧𝐜𝐨𝐮𝐫𝐚𝐠𝐞 𝐎𝐩𝐞𝐧 𝐃𝐢𝐚𝐥𝐨𝐠𝐮𝐞: 𝘈𝘭𝘭𝘰𝘸 𝘲𝘶𝘦𝘴𝘵𝘪𝘰𝘯𝘴 𝘢𝘯𝘥 𝘴𝘶𝘨𝘨𝘦𝘴𝘵𝘪𝘰𝘯𝘴. 🔄 𝐑𝐞𝐟𝐥𝐞𝐜𝐭 𝐚𝐧𝐝 𝐀𝐝𝐣𝐮𝐬𝐭: 𝘜𝘴𝘦 𝘧𝘦𝘦𝘥𝘣𝘢𝘤𝘬 𝘵𝘰 𝘳𝘦𝘧𝘪𝘯𝘦 𝘺𝘰𝘶𝘳 𝘱𝘳𝘰𝘥𝘶𝘤𝘵 𝘢𝘯𝘥 𝘱𝘳𝘰𝘤𝘦𝘴𝘴. How did you make your reviews powerful? Share your thoughts below.