You never get a second chance to make a first impression – Will Rogers
I remember very well that I attended the first sprint review before I knew what Agile, Scrum and a Sprint was. The presenter was called Mea and she was very enthusiastic about this event. It was easy to see that this was the highlight for her. She acted as a show master – later I learned that that role is called the product owner – and it was obvious why two thirds of her name was ‘Me’. Although the review should be more about the product than about her, the enthusiasm was disarming and this first review that I attended was energizing.
4 hours per month
According to the Scrum Guide it is recommended to spend 4 hours per month on the review with the scrum team and your stakeholders. I am afraid that in the annum 2022 ‘I am sooo busy’ has become such a cliché that we must be more conscious of our time. Let’s aim to get to 2 hours per month = 1 hour per 2-weeks sprint. To keep your stakeholders engaged to attend future reviews, they’d better perceive it as time very well spent.
This means that we must eliminate any waste that doesn’t contribute to the objective of the Sprint Review: demonstrate what was delivered with context and get stakeholder feedback. That is considered to be the most effective way to validate the assumptions that you had so far about what your stakeholders want. The demo of done work plus the stakeholder’s feedback are input for you to adjust the backlog (add, remove, adjust stories or priorities).
Have a close look at your reviews to eliminate anything that does not contribute to that objective.
Do you believe in love at first sight?
Will Rogers said over 100 years ago that “You never get a second chance to make a great first impression” and I still believe that is true. We always make an unconscious decision within seconds. Think of that moment you pick up the applicant for a new job. In the elevator to the meeting room, you already knew that the upcoming meeting will be a waste of time. Also ‘Love at first sight’ is evidence that first impressions are not easily forgotten.
But what does that mean for us? We want early feedback and show a product that is not finished, so we know the first impression will not be perfect. This makes the sprint review the most important ceremony. As Product Owners, we’d better be sure that the review is perfect and very relevant for the stakeholders.
Are your developers ready?
Our developers are knowledge workers and we know that they grow when they feel masters and feel purposeful. This has the risk that they may want to demo how difficult it was to deliver what they delivered, while that is exactly what you don’t want. You don’t want to show coding nor any other backend work. You want a demonstration of the feature that was delivered and how easy it is to work with that feature.
This means that you have to spend quite some time with developers to coach them how to demonstrate value. This is not the moment to show how smart a developer is nor the moment to justify what the team has been busy with. It is not about you (Mea!), nor about the developers. It is about the product and the (future) consumers of the product.
Before the review:
- Send out a detailed agenda early. After sprint planning you know what your team will most likely demonstrate, so you can already make clear to your stakeholders what they can expect.
- Invite the right stakeholders. Most likely you have multiple stakeholders and this sprint you may deliver good value to stakeholders A and B, but next sprint you have more value for A and C. If you want to keep your stakeholders engaged, don’t invite them for a review that has nothing in there for them
- Feel free to forward. The review is an open session. Be happy if one of your stakeholders wants to invite other stakeholders or experts. Always good to mention in the invite that they don’t have to hesitate to forward invitations.
The review itself:
- Emphasize that the review is only valuable with stakeholder’s feedback.
- Only demonstrate stories that deliver value and you want feedback on. Don’t mention spikes, investigation, foundation stories, etc. Good for you, but no direct value for business. Also don’t demo ‘phase 1’ if you know that in two weeks you will demonstrate ‘phase 2’. Unless you want feedback on phase 1 now, it is often a waste of time to demonstrate twice. The 2nd demo often starts ‘to refresh your memories’ with a short repeat of phase 1.
- The Review is more than a demo. Explain the context of a demoed story by briefly showing what was done before this story and what you expect to be the next piece after this demo. That should lead to the stakeholder’s confidence that we know this is not the finished product, but the best impression of the work done so far.
- The use of PowerPoint slides is OK as an introduction, showing the sprint goal, where you are in the PI, explaining next steps, etc. But limit the use of slides during the demonstrations. Let the developer explain what they will demo (“I want…”) and to who (“As a…”) and why that is so valuable (“So that…”). It may be difficult to deliver a story, but it should be easy to demonstrate a story if it was well written in the first place.
- When you deliver improvements to current functionality, it is best to show ‘as is’ for context (i.e. in your production system). That will make the improvement (demoed from your test system) very tangible.
- Record your meeting. Unfortunately, most of our reviews are virtual via Zoom, Teams, etc, but it has the advantage that you can record the session. This is very helpful for future reference (“how did (s)he do that?”). Don’t forget that also fellow scrum teams and IT colleagues are stakeholders who value a detailed look at a scene that was demoed quickly.
After the review:
- Send a link to the recorded meeting to all invitees. Especially the stakeholders that couldn’t attend, can watch the review at a time slot that is more convenient to them.
- Create deep links (very easy to do with MS-Stream, youtube, etc) to the various demonstrations, so that stakeholders can quickly jump to the scenes most relevant to them.
- Emphasize in the email that they have influence on the direction of the product only if they provide feedback.
What feedback do you have for me about this blog? How could I have made it more relevant for you? What other topic would you like me to blog about?