Post 6: Becoming Agile
Agile Meetings: Sprint Showcase
Introduction
Where Value becomes Visible
Agile ways of working build on each other and create a mindset shift in how teams think about their daily work. The purpose of the current section in the Becoming Agile series has been about explaining the foundational Agile meetings or “ceremonies”. These are:
Daily Standups
Sprint Planning
Sprint Retrospectives
Sprint Showcases
In this chapter, we will focus on the Sprint Showcase (also sometimes called the Sprint Review). The reason I prefer calling them a showcase, is so that everyone in the team is focused on “showing” something, not describing something or discussing effort put in, not value coming out. Showcases matter because they help teams to stay transparent, accountable, and connected to the people they’re making their products for, and why they are doing it in the first place.
Purpose and Goals
As a team working on becoming Agile, the Sprint Showcase is your ceremony for making what has been done visible. It sounds daunting at first, but helps establish a focus in each Sprint around working towards demonstrating the value they’ve created during the Sprint. They do this not through gantt charts or changing colours on a risk slide or verbs in a status update or task list, but by showing working outputs to engaged stakeholders and customers.
The Showcase serves several core purposes:
Show what the team has built - telling a story based on value delivered, not effort or excuses
Engaging the right people early and often to get meaningful feedback
Inspect the increment at the end of a timebox (Sprint) showing you care about what has been done, what is ready to show and what’s useful to see
Adapting your backlog - you can adjust priorities based on what you learn in your Showcase
Promote accountability by making the team’s progress transparent
Celebrating the successes along the way and allowing team members to shine and get positive reinforcement
A showcase is not to burden a manager with another meeting, they do not exist so a Scrum Master or Product Owner can deliver a boring PowerPoint presentation, smoothing over rough edges, or covering for the teams lack of meaningful outputs in the last Sprint.
If you’ve been in project management for any amount of time you might have seen monthly project status updates where everything is showing as “Green” and you’re being told how well things are going. Then right before things are meant to be delivered, it all goes “Red” and every risk becomes an issue for the Project Board to solve, and the Project Manager then asks for more time and to promise they will definitely get it done this time, and usually the request for more time is accompanied by asking for more people and more money.
The purpose of a Showcase is to cut through this style of project management. It shows everyone what is being done, and allows the expertise within the teams, the people who are doing the work, to have a chance to show up and be honest about what they’ve been doing and walking you through demos of their work. If no one has anything to show, that’s not just a sign of a quiet Showcase, it’s a signal that something isn’t working and needs to be fixed. If you’re nervous about Showcases because you don not think the team can articulate how what they are doing connects meaningfully to the business and customers - then you probably have a lot more than the Showcase to be nervous about - and no matter what happens, transparency is good, accountability is good. Opportunities for learning and feedback are good. Focus everyone on the good.
A great Showcase will help your team celebrate success. But it will also invite useful challenges, feedback, and conversations. A Showcase allows the team to come together and show up for each other and front up to the people who are paying for their work, others who care about it, and hopefully key customer groups who will use it when it is done.
Showcases build trust, and provides one of Agile’s most powerful early warning signs of project health: we said we would deliver something of value in this Sprint, and either we can or we can’t. Either way, what you learn will be something useful.
High-Level Format
A simple format for a Sprint Showcase might look like this:
1. Sprint Goal Recap
Product Owner: “Our goal for this Sprint was to launch password reset functionality for end users.”
2. Demo 1 – Live Functionality Walkthrough
Developer screen shares the actual application, showing the new user flow, error states, and confirmation messages.
3. Demo 2 – Hands-On Access
Stakeholders scan a QR code or access a shared link and get to try the new feature themselves, providing comments in small groups in real-time.
4. Stakeholder Feedback & Questions
“Can we allow non-email usernames?”
“Would this work for mobile biometrics for authentication and logins?”
“Could we have password reset be self-service?”
5. Backlog Adjustments
PO notes suggestions and commits to update stories for prioritisation discussion.
6. Next Steps
Product Owner briefly outlines expected priorities in the next Sprint and invites alignment.
Example: Interactive Demo Dialogue
Product Owner: “We aimed to improve the password reset process, which was a frequent source of user frustration.”
Developer: (screen sharing) “Here’s what we built, you will see the new reset link, email validation, and confirmation modal.”
Stakeholder: “Is this responsive on mobile?”
Tester: “Yes, we tested that yesterday, I will quickly show the mobile version now.” (moves to show mobile version)
Designer: “We also aligned the error message styling with the platform design system we showed in the next sprint and tested the colours for accessibility compliance.”
Product Owner: “Anything missing or confusing? The link for the feedback boards are around the room, or note it down and send to our group mailbox and we willl capture it in the backlog.”
Common Pitfalls of a Sprint Showcase
Here are red flags that your team isn’t getting the full value of the Sprint Showcase:
Pitfall 1: Nothing to Show
Causes
Stories are too large or vague to complete in a Sprint
No clear “Definition of Done”
Work wasn't prioritised effectively
Team focused on tasks outside the Sprint
Risks/blockers weren’t raised early
How to Fix It
Sprint Planning: Break down epics into small, testable stories with clear outcomes. Define "Done" upfront.
Daily Standups: Ask “What are we demoing Friday?” and track if progress maps to Sprint Goal.
Retrospective: Get team input and reflections on why nothing was demoed. Was the work too big? Were priorities misunderstood?
Pitfall 2: Only Managers Presenting
Team lacks confidence or doesn't feel ownership
PO or Scrum Master dominates the ceremony
Presenting seen as performance, not conversation
How to Fix It
Sprint Planning: Assign ownership of stories visibly. Link it to Showcase early so each person knows what they’re showing.
Daily Standups: Reinforce team ownership by having team members talk through progress.
Retrospective: Ask “How can we involve more voices at the next Showcase?” Rotate roles.
Pitfall 3: Lecture or Status Report Feel
Team misunderstands the purpose
Demo environment not working
Stakeholders just “listen” passively
How to Fix It
Daily Standups: Use blockers/questions to help teams prioritise demo-readiness.
Showcase Prep: Test environments and links ahead of time. Assign demo drivers.
Retrospective: Ask, “Did we show working value, or just talk about effort?”
Pitfall 4: Stakeholders Don't Show Up
Invites sent late or irregularly
Stakeholders unclear on value
Showcases are too long, too technical, or too boring
How to Fix It
Sprint Planning: Ask which stakeholders need to see what’s being built. Invite them early.
Showcase Prep: Share a short agenda or teaser one day prior.
Retrospective: Gather feedback from no-shows. Were they unclear on the purpose?
Pitfall 5: Presentation Challenges
Developers forget to frame for non-technical audience
Demo not rehearsed or structured
Goal wasn’t clear or achievable
Unplanned work or rework crept in
Focus drifted during the Sprint
Fear of awkward silence
Unclear roles in the demo
Team members unsure what to say
How to Fix It
Showcase Prep: Assign presenters for each backlog item. Practice demo flow. Ask: “What does the user see?” not “What code did I write?”
Daily Standups: Encourage open participation, not just one voice.
Retrospective: Ask “Who else could have presented?” to build confidence.
Retrospective: Ask “Who else could have presented?” to build confidence. Gather feedback on clarity. Did the audience understand the value?
Pitfall 6: No Backlog Updates Happen After Showcase
Feedback is heard but not actioned
No follow-up ownership
Product Owner doesn’t have time allocated
How to Fix It
End of Showcase: Summarise feedback and agree who will create new backlog items.
Sprint Planning: Start by reviewing updates and new priorities from the last Showcase.
Retrospective: Reflect on whether feedback was actioned or forgotten.
Diagnosing the “Nothing to Show” Problem
If your team finishes Sprints with little or nothing to demonstrate, it is impossible to ignore. After the Showcase, you will have your Sprint Retrospective that will give you some fixes you can take into your next Sprint Planning and Daily Standups.
When your team heads into the Retrospective activity, you have a real opportunity to learn why it happened. Then the team can carry the fixes through to their Sprint Planning and Daily Standups, everyone in the team can then be much more focused on making sure it doesn’t happen again. That is how each of these ceremonies we have focused on work together, these are inextricably linked and work together to drive your teams daily work towards becoming Agile.
Common Causes:
Poor Sprint Planning: your user stories are too vague, too big, or poorly understood.
Lack of focus: team is distracted by non-Sprint work and not focused on how their daily work leads to demonstrable value within the Sprint.
Hidden blockers: there are risks or issues that are not raised or resolved early enough in the Sprint to achieve your sprint goals and outputs.
Waterfall habits: teams are not used to getting work done on Sprints, and if deadlines shift, they don’t mind, that’s the Project Manager’s problem, they were saying it wouldn’t actually get done in the Sprint anyway.
Passive standups: no one escalating blockers or being shifting to unblocked work or to support unblocking work, and just carrying on as normal even when things aren’t working.
No “definition of done”: things feel "in progress" forever, they didn’t know what the end looked like, so kept adding things or polishing the turd instead of focusing on what actually mattered.
Prevention/Solutions
Getting disciplined around your Sprint Planning and Daily Standup is the key prevention. These are the ceremonies where you will directly implement what you learn from your Retrospectives and ensure you have things to show at Showcase. The daily honest answers to these questions will help ensure that by the end of the Sprint you will have things to show:
What did you complete yesterday?
Are there risks or blockers? Do we need to pivot?
What’s most valuable to finish next?
Coach your team to treat each Standup as a micro-course-correction, not a verbal checklist or something they need to get through to “bluff” the Scrum Master. The goal is to finish the Sprint with something to show - not just activities and going through the motions, but delivering something of value.
Tips for Better Sprint Showcases
Keep it Focused: demo only what is “Done.” Don’t confuse effort with output
Be Interactive: within the construct of focusing on showing - Invite stakeholders to ask questions or even try features live
Show Context: connect what was built to why it matters
Let the Team Own It: each team member should speak to what they contributed
Gather Feedback in the Room: don’t wait for later to if you can avoid it, ask what people to tell you what they are thinking in the Showcase. This doesn’t always mean opening the floor or going around the room, knowing some people are introverts and might not speak up in front of the group, plan to have channels to collect their input as you are showing and leave some space for feedback in the agenda.
Prepare, Stay Focused on the Value of the Output: make sure presenters are clear about how what they are showing makes the end user experience better, saves time, money, and provides something people want and need.
Conclusion
Sprint Showcases are not about being a presentation or a performance, they are a mirror. If they’re quiet, awkward, or underwhelming, that’s okay. Maybe the output of the Sprint was too. Whatever happens, good or bad, talk about it in your Retrospective. In the Retrospective ask the team:
“How did we go? How did you feel in and after the Showcase? What would have made this Showcase more valuable? What did we do well that we want to do the same in the next one? What can we do different?”
Every showcase is an opportunity to learn and demonstrate value.
A Showcase is a chance for your team to be proud of their work, to get feedback, and to stay aligned with real users and real priorities. When you shift the mindset from “we’ve been stressed” and “we’ve been working so hard” to “here’s the value we delivered” and “how cool is this feature?”, you know your team is moving in the right direction and truly becoming Agile.
References
Adkins, L. (2010). Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition [PDF]. Addison-Wesley. https://masterinagile.org/wp-content/uploads/2022/10/Coaching-Agile-Teams.pdf
Atlassian. (n.d.). Sprint Demo: What it is & How to Conduct One. Atlassian Agile Coach. https://www.atlassian.com/agile/project-management/sprint-demo
Cohn, M. (2023, December 6). Sprint Review meeting: What it is & how to run it. Mountain Goat Software. https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting
Iqbal, M. (2025, June 23). Trust but verify at the Sprint Review. Scrum.org. https://www.scrum.org/resources/blog/trust-verify-sprint-review
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. https://scrumguides.org/scrum-guide.html#sprint-review
Wolpers, S. (2020, April 27). Remote Agile (Part 7): Sprint Review with Distributed Teams. Age‑of‑Product. https://www.scrum.org/resources/blog/remote-agile-part-7-sprint-review-distributed-teams
Wolpers, S. (2019, November 12). 15 Sprint Review anti‑patterns holding back Scrum teams. Scrum.org. https://www.scrum.org/resources/blog/15-sprint-review-anti-patterns
Zen Ex Machina Pty Ltd. (2021). Checklist 7 – Sprint Review [PDF]. Zen Ex Machina. https://info.zenexmachina.com/hubfs/Checklist%207%20-%20Sprint%20Review.pdf