I’m sure if you ask your project team what the most stressful scrum event is, they’ll say “sprint review,” especially if you’re giving a demo. It’s understandable. Anyone who has had to learn the hard way how to do a scrum sprint review knows how it feels when the entire team is staring at you and the customer expects to see the finished product.
Of course, I’m a little exaggerating. However, the fact remains that the sprint review is one of those public statements that might cause worry and anxiety.
Consider whether there are any additional issues that the client could be interested in.
- configuring databases,
- adding a mobile version,
- updating the libraries,
- planning likely completion dates,
- reviewing product backlog management.
The content of a sprint review meeting must be useful to the scrum team and stakeholders.
I strongly advise writing down the agenda and presenting it to the group point by point at the start of the meeting. This way, you (the leader) can be sure you didn’t overlook anything and that all issues have been covered, and the customer will know exactly what to expect right away.
This, I’ve discovered, works very effectively in the start of any collaboration. Particularly with clients who haven’t yet had the chance to learn or operate with scrum.
How to prepare and conduct a scrum sprint review?
Make stable environment and application version available no later than the day before the meeting
And when I say the day before, I mean at least 24 hours prior. Not at 11.30 p.m. on Wednesday for the demo on Thursday at 9.00 a.m. Nobody wants to stay up all night preparing for an event. I’ve also seen that when anything is done at the last minute, it ceases to function right before the meeting. This is the universe’ law; there is no need to oppose it. It’s preferable to look after your (and your team’s) mental well-being by showing less but from a stable version.
The stable version is ready. Now prepare a list of things you want to show off
There are many methods to show completed tasks and new functionalities. However, my favorite so far is describing the tasks while simultaneously presenting their results in the application. It’s a good idea to arrange your tasks in a logical order because it will make it easier to smoothly navigate the app, e.g. adding a new user -> displaying user data -> editing user data.
Create user profiles in advance
You should develop appropriate browser profiles in advance if you wish to offer different application views for different users during the demo. You can effortlessly move between profiles instead than logging in and out every time. It’s a minor detail, but I guarantee it will cut down on meeting time and reduce tension.
Prepare all necessary hardware and devices
When giving a presentation on a mobile version, bring an actual device (ideally one that will be used by the end-user) to offer the customer a real sense of the app’s navigation, operation, performance, and other UX and UI elements.
Okay, the environment is set, the tasks have been completed, user profiles have been made, and the mobile device has been charged and is ready to go. It’s time to…
Organize a rehearsal before the actual sprint review
It should ideally take place in front of the entire team. Then you have the opportunity to consult and agree on what will be presented and how it will be presented. Unfortunately, we can’t always afford to get the complete crew together. But, rather than doing nothing, it’s still preferable to practise in a smaller group (with project managers or quality assurance professionals) and collect the last valuable comments and observations.
Examine your communication system. I know that typically works, but it’ll take you a minute to double-check whether screen sharing is enabled or if the internet connection is of sufficient quality. If the client communicates with you via a platform you rarely use in your daily life, it’s a must.
Attempt to speak in the same language as the client during the rehearsal. It’ll mostly be international English, but I’ve already done some in Polish and German, so cheers to all the locals!
What do you gain out of a rehearsal besides improving your self-esteem? The second law of the cosmos frequently comes to the fore, and a completely new bug appears that wasn’t there before. Typically, there are a few extra pairs of eyes that can spot an inaccuracy.
Wait a second, I know what you’re thinking: a quick cure, right? No, no This bug should be logged like any other, and at the sprint review, simply admit that it has been discovered (and is being properly fixed).
Hire a “secretary”
Last but not least, assign someone to take notes throughout the discussion. You’ll have enough on your mind that day, and having someone assist you with the notes will be a huge assistance.
