I often meet teams who feel they have negative sentiment within an organisation. Some teams feel like they are delivering work too slowly and stakeholders see them as a cost to the organisation rather than a value stream. Teams can feel rushed, overworked and that they are just treading water to keep up with the demands being placed on them. It’s the classic example of teams who are too busy trying to drive the car that they’ve not got time to think about whether they are going in the right direction. Whenever I hear this I ask if the team does a sprint review. The answer is - almost universally “no”.
It’s like driving with a blindfold on, you have no idea which direction you are going.
Sprint reviews are an essential part of the agile development process. They provide an opportunity for teams to demo their progress and receive feedback from key stakeholders. Yet, for teams that have been putting off sprint reviews, the thought of conducting one can be daunting. In this blog post, we’ll provide guidance on how to conduct the perfect sprint review that is lively, has demos, is interactive and makes people look forward to the next one.
What is the purpose of a sprint review? As the scrum guide states…
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed
It’s very light on what it actually looks like - so here’s my advice on getting the perfect Sprint Review
The roles
To help with the flow for the Sprint Review, you should dedicate the following 4 roles. These could be rotated any time
- The Facilitator will introduce each section, and help guard against any deviations from the agenda and trigger any votes
- The Notetaker will observe and write down any discussions, actions and decisions taken in the meeting to ensure the team
- The Timekeeper will ensure the review is moving rapidly and each agenda item is reviewed.
- The Decider will be present to make any decisions during the event. They ensure discussions are focused on the product goal rather than other business initiatives. Typically they would be the product owner
A facilitator, a notetaker, a timekeeper and a decider prepare for a sprint review (made with midjourney)
The cadence
Your team deserves to be able to show their work. If the sprint is overloaded then the review seems like a waste of time. In reality it is a moment to look at the work being produced and make sensible decisions about future work. As a result the review should not only be scheduled, but you should have a templated agenda on what should be in it. Ensure this agenda is updated well in advance of each sprint review.
The scrum guide suggests a maximum 4 hour timebox, but try to make it as short as possible to keep it engaging and exciting for the attendees. If you haven’t done one in a while maybe 1 hour is a good target, and if you finish early then so be it.
Schedule the sprint review at a convenient time for the team members and your most important stakeholders. I have advice for teams that struggle to diarize them later.
The agenda
At the start of the sprint the team commits to some work.This is a great template for the sprint review agenda. Imagine what you might be reviewing at the end so that you focus on visible work rather than purely enabling features. Ensure your definition of done includes any relevant steps that are required to add this to the sprint review. Remember to ask yourself
if we can’t review the work, how do we know the work is done?
This will really help set up the agenda so all the attendees know what to expect.
The meaning
Start the session itself with the product goal or team mission. Repeating this in every review embeds it in the team and the stakeholders. It also helps with focusing any discussion onto what’s important for the team. Try to map the product goal to the overall company mission, this helps stakeholders understand why the team exists.
If there are longer running epics, then visualising the progress is key. This helps stakeholders know what to expect in the future. Use flow diagrams and burnup charts to bring it to life. This is particularly important in complex environments where the value is not always clear.
Also make sure you are referencing any data & insights that have taken you closer towards that product goal. Include any customer behaviour, marketing highlights or site reliability that made an impact. (either positive or negative)
A product owner tries to explain why this team exists in the organisation as a whole (made with #midjourney)
The truth
Teams often fear saying what the sprint goal was at the start of the sprint. It often reveals their inability to forecast well. I urge teams to be entirely transparent. There is always a reason why team members can’t deliver on the commitment - share that with the wider business. This makes the discourse more mature and can focus on how stakeholders can help. I’ve seen cases where stakeholders help discover alternative solutions that the team felt were outside their control.
Another advantage of sharing the original sprint goal is it enables the team to focus on that commitment. After facing stakeholders and having to say they failed to deliver a few times they learn to be more realistic.
The format
A-lot of people call the review a “Sprint Demo”. This is an antipattern. The scrum guide also states…
The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
As a result, you should encourage interaction by using Voting, QandA and use it as a forum to help craft the roadmap for future sprints. I like Mentimeter as a product that allows for fast interactive voting based on things being discussed.
For each review item consider how you want people to review the item. Choose an appropriate format. New features might need a poll to decide on the suitability for the customer. Experiments might require a focused discussion on next steps. The format for each should be decided before the meeting.
When reviewing an item you should bring it to life with the most fidelity you have. This might be a wireframe for early work, with references to the user journey. For work later in the journey it could be screenshots or pre-recorded walkthroughs. Another key thing to include is any customer insight that helps tell a more complete picture. Include user behaviour data that can augment the message you are trying to deliver.
Be cautious of live demos. Sometimes things break so if you intend to do a live demo. Always have a pre-record waiting to fall back on (plus it’s good to have a document that outlives the live demo). I tend to use Loom for this pre-record.
The future
It is important to share what is coming next. This shouldn’t be a gantt chart - instead use a simple “Now, next, future” roadmap. It’s also a great forum to ask for possible ideas in the areas you are laying out. Confident teams use this as a forum to discuss innovations and technology. For example “Would ChatGPT be an appropriate technology to solve our problems?” Remember to focus things on the product goal, highlighting any insights you need to make your point.
The template
So the perfect sprint review should probably follow the following format
- Introduce the product goal
- Share data & insights towards that goal
- Highlight the sprint goal
- Highlight the key challenges the team faced
- Review each of the items in the sprint
- Talk about the future towards delivering the product goal
But…
I often see teams unable to set sprint reviews in people’s calendars. Reasons include: competing priorities, timezone differences and absence. I have some further advice to help make the sprint review asynchronous.
- Pre-record any demos. Use products like loom for a low hassle way of getting snappy 2 minute demos recorded before the session
- Use your company’s messaging service as an anchor. Create a channel for all your product team’s sprint reviews.. Add the demo videos as individual threads and invite comments. Link to the polling software to survey your distributed stakeholders
- Share a summary of the feedback a few days later, also a good opportunity to tease what might be appearing in the next sprint
By following these guidelines, teams can conduct effective sprint reviews that engage stakeholders, showcase progress, and drive the development process forward. By making sprint reviews interactive, lively and with clear demos, it will make people look forward to the next one. Remember to schedule the review at a convenient time, invite the right stakeholders, and to follow up on any feedback received during the review.