Of course, I’m exaggerating a bit. But this doesn’t change the fact that sprint review is one of those public speeches that can trigger fear and anxiety. 

In this article, I’ll introduce a few tricks that help me personally to successfully conduct a sprint review that is valuable to the client and the team, without me getting a heart attack. 

INB4: What is the main purpose of the sprint review?

Before I move any further, you need to ask yourself a couple of questions. What are the client’s expectations of the sprint review? What information would they like to get from this meeting?

According to the scrum methodology, the sprint review determines whether the sprint goal has been achieved, i.e. the client wants to know what has been delivered and what new functionalities have been added to the application.

Going a bit further, consider whether there are other issues that may interest the client (or key stakeholders). e.g:

• configuring databases,
• adding a mobile version,
• updating the libraries,
• planning likely completion dates,
• reviewing product backlog management.

Whatever is covered in a sprint review meeting must have real value for the scrum team and stakeholders

I highly recommend writing down the agenda and presenting it point by point at the beginning of the meeting. This way, you (the leader) will be sure that you didn’t forget about something and all topics will be covered, and the client will know straight away what to expect. 

I’ve noticed that this works particularly well at the beginning of any cooperation. Especially with clients who haven’t had the opportunity to learn or work in scrum yet. 

How to prepare and conduct a scrum sprint review? Practical tips

🕘 Make stable environment and application version available no later than the day before the meeting

And by day, I mean at least 24 hours before. Not Wednesday 11.30 p.m. for the demo scheduled at 9.00 a.m. on Thursday. Nobody wants to stay up all night to prepare. I’ve also noticed that when something is done last minute it stops working just before the meeting. This is the law of the cosmos, there is no need to fight it. It’s better to take care of your (and your team’s) mental comfort and show 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

If during the demo you want to present various application views for different users, you should create appropriate browsers profiles in advance. This way, instead of logging in and out each time, you can smoothly switch between profiles. It’s such a small thing but I promise it will shorten the meeting time and reduce your stress.

💻 Prepare all necessary hardware and devices

When presenting a mobile version, you should bring a physical device (preferably one that will be used by the end-user) for the presentation to give the customer a real feeling of the app’s navigation, operation, performance, and other UX and UI features.  

Okay, the environment is ready, the tasks are prepared, user profiles are created, the mobile device is charged and ready to rumble. Time to…

🎤 Organize a rehearsal before the actual sprint review

Ideally, it should be held in front of the entire team. Then you get the chance to consult and agree on what specifically will be presented and how. Unfortunately, sometimes we can’t afford the luxury of gathering the entire team. But it’s still better to rehearse in a smaller group (with project managers or quality assurance specialists) and collect the last valuable comments and observations, rather than do nothing at all.  

Check your communication platform. I know it usually works but it will take you a minute to check whether the screen sharing works or if the internet allows for a high-quality connection. It’s an absolute must if the client communicates through a platform you hardly ever use in your day-to-day. 

During the rehearsal, try to speak in the language you communicate with the client. Usually, it’s going to be international English but I already have done some in Polish and German, so cheers to all locals out there! 

In stressful situations, we tend to suddenly forget the simplest words. I have some glorious examples of “whatchamacallits” during my sprint reviews…My tip? Write down all the keywords, or the outline of your presentation. Just in case…

Apart from boosting your self-confidence, what do you get from a rehearsal? Often, the second law of the cosmos comes to the fore, and suddenly there’s a brand new bug that wasn’t there before. Usually, because there are a few extra pairs of eyes that can spot an error. 

Hold up a minute, I know what you’re thinking – a quick fix, right? A big no, no – remember that things done last minute never work? Log this bug like any other, and during the sprint review just openly admit that it has been found (and is being properly fixed). 

✍️ Hire a “secretary”

Last but not least, appoint a person who will take notes during the entire meeting. You will have enough on your mind that day, and somebody helping with the notes is an immense help. 

Now take a few deep breaths and start the sprint review meeting! 

The most frequently asked questions about sprint review

At least those, I’ve come across in my day-to-day…

🐛 Is it worth showing the fixed bugs from the previous sprint?

Yes, but in my opinion, only in two cases:  

• if the bug was reported by the client and they need feedback,
• if you spent a significant amount of your sprint time fixing this bug.

🤷‍♀️ Should you even conduct a sprint review, if the given sprint included backend tasks only?

A meeting summarizing the sprint should always take place. Of course, if the customer isn’t a technical person, it will be more difficult to explain in detail what has been done. Don’t worry though, you can always simplify, e.g. instead of showing 100,000 lines of code, you can use the Postman tool or the console for visualization.

👩‍💼 Who should lead the sprint review demo?

Personally, I am a supporter of the rotational approach to leading the demo. All team members including project managers and QA specialists should be in the mix. Everybody joins their skills together to work for the project’s success, so this rotation allows everyone to feel responsible for it. In addition, the stress of organizing sprint review meetings is evenly spread over the entire team, which also strengthens the bond of sharing the same burden. 

🎥 What if I recorded a demo with the rest of the development team and sent the video to the client instead?

What a tempting option that is. Well, it is even practiced, usually when the client is not able to attend the meeting for some reason, or the presented functionalities are very complex, and recording them is easier than a live presentation. Plus, if something goes wrong you can always start recording again. 😉 

Nevertheless, I don’t recommend making a habit out of it. Recording sprint reviews usually take up more work and time than a good old meeting.

How to conduct your first successful sprint review? Summary

Completed work is one thing but showing off what you did (or didn’t do) is another. You don’t need to be a scrum master or have your internal scrum teams present at every sprint planning meeting, to provide valuable input to your clients. With a bit of preparation, you will be able to nail your next sprint review.

To sum up this scrum review article, a few things to remember:

• Yes, leading a sprint review is stressful but good preparation and practice make each subsequent one easier. You might even get used to them! 
• It is you who present the results of the work in a given sprint. But the entire group collaborates and shares responsibilities for the quality of those results.
• Sprint review is just one of the many similar meetings that you will have to attend or lead. So even if something didn’t go your way in the last sprint, the next one will only get better.

To finally cheer you up, I can 100% guarantee that most of the experienced people you work with today had a nightmarish demo that caused them a cold sweat and heart attack. Now, it’s probably a funny anecdote told with nostalgia. 

Until then, keep your head up!