Sprint Review for Business Analysts: Tips and Tricks

What can be more rewarding, and yet thrilling, than being dedicated by your own Scrum team to run the Sprint review? Well, this, in turn, raises a lot of questions on what exactly you show during the review. What is the sequence of steps? Whom do you invite? How deep and technical do you want to go? And many other questions.

Business Analysts do many things and possess many skills. And one of the most important skills is the ability to present! Present the results of your own research and analysis, or the results of your teamwork.

In this article, I'll share my main recommendations for conducting productive and engaging Sprint Reviews by business analysts.

Before we go further, don't forget to download the Scrum Cheat Sheet for IT Business Analysts that comes along with a free video tutorial!

Sprint Review is Not just a Demo!

The first thing that you need to know about Sprint Review is that it's not just a demo.

According to the Scrum Guide:

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.

Now, with this definition, the ultimate goal is to really have a check-in between the Scrum team and the stakeholders, get feedback on the results of the current sprint, and if needed, adjust future plans based on this feedback. So, it basically comes down to showing and reviewing the current state of the product, talking about what you've built so far, checking if it all makes sense, and having a conversation about future sprints.

What do we include in Sprint Reviews?

For a 1-hour Sprint Review session, I recommend using the following agenda:

• Introduction – 2 min

• Sprint Goal – 5 min

• Sprint Statistics – 3 min

• Demo – 40 min

• Known issues and Next Steps – 5 min

• Q&A – 5 min

And here’s how the meeting will flow:

1. During the introductions, you greet everyone and introduce yourself and the agenda. You may mention that the meeting will be recorded and explain how you want people to raise questions, and so on.

2. Then remind everyone of the sprint goal. It should be something business-friendly, so instead of just listing a bunch of user stories and tasks that you have delivered, say what capabilities you were supposed to build – like enabling payment or shipping options for international users. Something that business users and SMEs can relate to.

3. Then I recommend showing the basic stats about the sprint and the team performance. This is where you can talk about story points that you successfully delivered, what the team velocity was, and how many defects you raised and closed – but keep it really short and business-friendly, so that the audience can resonate with what you're presenting.

4. Then get to the actual demo part. This is going to be the main piece of your sprint review. Usually, there are 2 main approaches to how you want to run the demo.

   1. The first approach is to literally go story-by-story (or task by task) and show each user story from an end-user perspective and also how it was implemented: so you demo the UI and then switch to the backend, showing how things work under the hood.

   2. Another approach is to have a more business-friendly flow, where you focus not on individual stores but on a certain user journey and the business capabilities. So, in this case, you run the demo only from an end-user perspective.

   3. Both of these approaches are totally valid. You need to decide on the approach based on who your stakeholders are and what your product is. That will influence what approach you're going to choose.

5. After you're done with the demo, say what's going to happen next – what's coming in the next sprint or several sprints. This way, the audience will connect what you've just demonstrated to what's coming later. And if there are known blockers or issues, make sure to call them out so that the audience is aware of things that may slow you down.

6. Of course, at the end, leave time for questions and answers. Proactively seek to get feedback from your users and stakeholders. The absence of questions or comments may not be a good sign – it may mean that the audience may be disengaged, or they actually may have tons of questions but they just don't find this meeting safe to raise them. To seek feedback, you may try calling your key stakeholders by name.

Preparation for Sprint Reviews by Business Analysts

Never allow improvisation and go unprepared to Sprint Reviews. You need to be very serious about getting ready, and the best way to go about it is to have dedicated preparation sessions on the calendar.

So schedule preparation and, if necessary, dry run sessions so you can prepare the storytelling and your slides, rehearse the demo part and even get ready to answer potential questions.

For example, if the Sprint Review is scheduled on Wednesday, I'd recommend having one 30-minute session the previous Friday, then another 30 minutes on Monday, and 1 hour dry-run on Tuesday.

For these preparation calls, of course, you don't include the

stakeholders, but you include your key team players and start putting together content for the Sprint Review presentation. I always recommend having a PowerPoint slide deck where you put all your main topics, with Sprint goal, main achievements, open issues, and next steps so that you can present it during the actual Sprint Review and then circulate these slides afterward.

Who is Doing What during Sprint Reviews?

In my opinion, the Sprint Review should always be a team effort. It means that everyone should know their role in the preparation and running of the review, and you need to agree on these roles internally within your team.

For example, the team's work may be organized in the following way:

1. Scheduling the meetings will be done by the Delivery Manager or the Scrum Master.

2. Preparing summary slides and the sprint stats for the presentation deck – again, this can be done by the Delivery Manager or Scrum Master.

3. Reminding of the Sprint Goals - this can be done by the Product Owner.

4. Demo - by default, I recommend that BAs show their respective pieces. However, to avoid switches between many presenters, I'd recommend sticking to a maximum of 3 presenters during the demo part. When you have too many presenters and switches between them, this may distract the audience.

5. After the demo, when you talk about the Next Steps or blockers - usually it’s the Product Owner or the Lead BA giving an overview of the plan for the upcoming sprints.

6. Q&A – usually moderated by the Delivery Manager or Scrum Master.

Learn More

Interested in learning more? Download the Scrum Cheat Sheet - your all-in-one summary designed specifically for IT business analysts. As a bonus, it also includes a 10-minute video lecture on Scrum for BAs.

Conclusion

Even though you want to be serious and organized with the sprint reviews, you shouldn't go too far and make it a formal acceptance event for the stakeholders.

You will most likely have a separate cycle of meetings for user training and formal user acceptance. The Sprint Review is more of a regular check-in to show how things are going and get immediate feedback that you can incorporate into your product development.

How do you run Sprint Reviews in your team or organization? Are you facing any difficulties engaging stakeholders or the team for regular reviews? Please let me know. I'd love to hear from you!