Have you ever been in a meeting and wondered what was its purpose, how it will be conducted, and why you were invited at the first place? This might also be what your stakeholders think about when they join your Sprint Review!
Let's put on some simple guidelines to improve your chances of having meaningful and valuable Sprint Reviews.
Design your Sprint Review during the Sprint Planning
You might wonder when is the best timing to prepare your Sprint Review. Some teams allocate time on the last day of the Sprint to make sure that they have everything in place before the Review starts.
This is a good practice in the sense that preparations for a demo can take time, and that doing rehearsal can certainly help avoid embarrassing moments during the Review.
Is this enough?
Are we inviting stakeholders well in advance? Have we built our product while keeping in mind what value we want to demonstrate at the end of the Sprint?
In order to avoid ending a Sprint with nothing valuable to showcase to the stakeholders, I recommend to draft the Sprint Review at the beginning of the Sprint Planning. Precisely, while setting up the Sprint Goal, here are a few questions that you may want to clarify:
- How do we know if we have achieved the goal?
- Who is going to benefit from this goal?
- What are the (assumed) benefits that we will provide?
Once the Sprint Goal has been clarified, the following Sprint Review's elements should come up easily to the team:
- Which stakeholders to invite
- What parts of the product to showcase
- What assumptions to test / what feedback to collect
Having this information clarified at the beginning of the Sprint Planing will not only help your team build a Sprint Backlog in a purposeful way, but it will also provide a solid common ground for the team to make better decisions, tradeoffs, replanning, etc. during the Sprint, since even if the scope of the work changes, the expectations towards the Sprint Review will remain the same.
Invite your stakeholders early, with a clear purpose and agenda
The Sprint Review is an open door for all stakeholders to see the product, and provide feedback to the Scrum team. The Product Owner is expected to identify the right people and to invite them to participate to the Review.
Now imagine that your Stakeholder is Elon Musk. Beside stating that he would not join a meeting without agenda, he is also well known for his three meeting rules that he set up at Tesla back in 2018:
- No large meetings.
- If you're not adding value to a meeting, leave.
- No frequent meetings.
Along with these rules, Elon Musk also emphasized on keeping meetings short, and on preparing the meetings in advance in order to improve their effectiveness.
If we apply these principles to the Sprint Review, we can come up with a list of must do preparations in order to invite stakeholders to the event.
- Make a clear Agenda (purpose, contents, timeline)
- Set up clear expectations for the participants to contribute
Supposing that your team is delivering three new features during the Sprint, each feature addressing to a specific stakeholder's need; here is a possible invitation email content you may want to send them:
Remember that this event is the best opportunity for your Scrum team to interact with stakeholders and collect precious information that will guide you on making better decisions for making a more delightful product. Make sure that you don't miss it!
Use a checklist to avoid missing preparations
Here we are, Sprint Review has started and it is now time to show the key feature of the event!
Until the team realized that they haven't deployed the latest update to the demo server to fix a critical issue... Blue Screen moment.
We are humans, we make mistakes, we forget. But this is not a fatality!
In theory, the Definition of Done should cover enough aspects of the product so that everything is in place for showcasing it during the Sprint Review. However it might be confusing to mix the purpose of meeting quality standards and get ready for the Sprint Review with it. This is why I recommend to make a simple checklist of all necessary preparations before the Sprint Review.
- All completed work has been merged to the target branch
- All merged branches have been deleted
- The latest version of the target branch has been deployed to the demo server
- Demo server Database has been reset with the necessary test data
- A dry run for each demo has been made on the test server
- The Sprint Summary document has been created
- Velocity chart has been updated
- There are enough chairs in the room
- Coffee and chocolates have been prepared for the attendees
This checklist can be made very simple first, and progressively improved on the way to address any additional needs.
These three guidelines contribute to be more intentional, more prepared, more confident to hold Sprint Review. Note that they won't necessarily make it a delightful event for your stakeholders, but this is something that you can figure out! Continuously ask your stakeholders what would make the next Sprint Review a better event, and keep improving ❤️
