Call it a ceremony, event, or ritual - the most important one in Scrum is the Sprint Review. Equivalent activities in other frameworks can take it’s place, or whatever you call yours, as long as a few things are happening.
Let’s get this out of the way first - THE SPRINT REVIEW IS NOT A DEMO. A demo might be a small part of your sprint review, but demoing is not the point. Work should be completed in small chunks throughout the iteration, which means we should be getting acceptance throughout the iteration, which means we need to demo completed work as soon as it as done, as soon as possible, throughout the iteration. If the first time your stakeholders or PO are seeing your completed work is during the Sprint Review you should probably focus on that before trying to improve your reviews.
If it’s not a demo, what is it?
The sprint review is the place to actually look back at what you worked on and how it went, what new information has come to light, and how that’s going to change your plan going forward. If you work in sprints and do the goal or commitment thing, then this is where you review how well you did against your plan to help you adjust your plan going forward. If you’re working in a flow based system like the Kanban Method this is when you look at things like your throughput, cycle time, SLEs, and other information to help you better manage your work.
So what should a sprint review look like? What do we do? How do we run one?
Using the Scrum Guide as our starting point we’ll timebox it to 90 minutes for a 2 week sprint.
I’d suggest to split it into 2 phases - start at 45 minutes each and see where the right balance is for you - the first phase is for the Scrum Team, the second phase includes stakeholders.
For the first phase with the team we’ll:
review our plan vs reality for team availability and actual time in the sprint
review each work item that was complete, what did we learn?
review each work item that was incomplete, what did we learn?
based on those things we learned (uncovered dependencies, clearer understanding of effort required, alternative solutions uncovered) how will this impact any future plans?
Phase two we’ll get our stakeholders in the room and:
share what was complete and what was incomplete and how this impacts the current plan
demonstrate the entirety of the product increment - this means show the new functionality in a production like environment as ready to deploy - ideally a key stakeholder would interact with the product instead of this being a demo by the team or PO
discuss information about product strategy, market fit, stakeholder needs, or anything else that impacts or requires adjustment to the current plan based on the information shared and the functionality that is complete
Depending how you look at it this is either the last event or the second to last event in your sprint (some consider the retrospective in between sprints, others say it’s the last event in the sprint).
If I’m running 2 week sprints that start on Wednesday and end on a Tuesday my preference is to have the sprint review on Tuesday morning - the sprint officially ends the minute the review starts (usually the first activity in the review) - we do the Retro on Tuesday afternoon, then planning on Wednesday morning before kicking off our sprint Wednesday afternoon (1 week sprints are very similar, just more compressed timeboxes)
With these thoughts take some time to reflect on your review and see if there’s anything you can change to make it more effective and get some of the real intended value out of it!