How to Get the Most Out of Sprint Reviews: An Interview with Scrum Master Henrique Ruocco

The sprint review is a crucial part of the scrum process, allowing development teams to show stakeholders all the items they created during a sprint and collect those stakeholders’ feedback. But how do you maximize the effectiveness of this process?

We sat down with scrum master Henrique Ruocco to discuss best practices for the sprint review. Since joining Programmers Inc. in 2017, he has helped countless clients reach their business goals and has been a vocal advocate for scrum processes. Discover his insights on sprint reviews, collecting the best possible feedback from stakeholders, and more below.

What is the goal of the sprint review?

Henrique Ruocco: From my point of view, we have three objectives for the sprint review. The first is to inspect the increment. The team usually presents the finished increment to stakeholders, showcasing all the finished items.

The second is, in my opinion, the most important part of a sprint review: getting feedback. We need to gather all the feedback from stakeholders, including product owners, customers, and other interested parties. We should ensure the product aligns with their expectations and needs.

 The final objective is to adapt and improve. Based on the feedback, the product owner (PO) can make some adjustments to the backlog. They may add new items, stories, priorities, or details to refine upcoming sprints. 

How long should a sprint review be? Because, of course, you want to have all the time you can to gather feedback, but you also don’t want to exhaust people.

HR: It depends on the complexity of the work and the amount of feedback that needs to be discussed. However, I’d recommend the sprint review to be a maximum of four hours. It should be long enough to achieve and discuss all the objectives and the feedback but not so long that it becomes unproductive or boring. 

How would you allocate time during that 4-hour meeting? How much time should be spent doing a demo, facilitating feedback, and other activities?

HR: It depends on your personal preference. For me, I begin with an introductions period. I think it is important to say hello to everyone. Then, I quickly explain all the items that will be covered during the call. So, I’d say five minutes for the whole introduction.

Then, I try to allocate most of the time for the demonstration and the feedback period. We start by demonstrating the completed work. The dev teams show off the functionalities of all the items developed during the sprint that are considered done.

The definition of done (DoD) is important here. It demonstrates that the item is really finished and ready to be deployed into production.

After all the demonstrations, we have the feedback period. Here, the stakeholder tells the development team if everything is good and if it all makes sense for their business objectives. The feedback period ensures everyone is on the same page.

Then, we can discuss whether the sprint goals were met. And finally, we can do a product backlog review. Based on the feedback we received, we can discuss some changes and reprioritize things. However, this is just a quick discussion because most product backlog prioritization will take place in the sprint planning.

You alluded to stakeholders earlier and I’m curious: Who all do you think should be at a sprint review both from the development team and from the client?

HR: The sprint review is a collaborative event, so we will include the entire scrum team, including developers, the scrum master, and the product owner. And, very importantly, we need the key stakeholders. The key stakeholders could include customers, users, and managers. This is anyone who is related to or interested in the product.

We need to have all these people in the call to provide us with valuable insight. Their feedback ensures that we know what our goal is and that we are in good shape for the next sprint.

Absolutely. You’ve mentioned the feedback and how important it is several times. What do you think is the most effective way to maximize the amount and quality of stakeholder feedback you get during the sprint review?

HR: I believe the most effective way to facilitate stakeholder feedback is to create an open and welcoming environment. This environment encourages stakeholders to ask questions, express their concerns about the product, and provide some suggestions.

Of course, you also need to keep the meeting focused on soliciting feedback and ask good questions to get more specific feedback from stakeholders. It helps to simulate some real scenarios for stakeholders to help them understand the product’s functionality and make sure that everyone is on the same page.

After the meeting, you can make some decisions based on the feedback that moves the product in the right direction.

Completely agree. Receiving and recording feedback is just the first step. Next is incorporating that feedback into the product plans and how the scrum team goes about its business. So how do you ensure the feedback received from the sprint review is used during the next sprint and while managing the backlog?

HR: Usually the scrum team, especially the product owner, will capture all the feedback during the meeting. Then, they should categorize and prioritize it based on the business value.

The business value could be whatever the product owner sees as being most important for the client, including return on investment, size of the user base, and more. The feedback that aligns with the product vision should influence the next sprint goal and the product backlog.

If there is feedback that feels out of context, we discuss it with the stakeholders during or after the sprint review to understand why it came up. For example, if a stakeholder brought something up that was unrelated to the product itself, it’s worthwhile to ask them whenever possible to explain why it came up. In my opinion, sometimes feedback may not make sense initially, but the stakeholder may be seeing something you didn’t see.

We’ve talked a lot about how an ideal sprint review should go. But, of course, we know sometimes things don’t work out the way we intend them to. What are some of the common mistakes people make with the sprint review?

HR: Yeah, unfortunately, I’ve definitely seen mistakes [laughs]. The biggest mistake is not preparing yourself adequately for the meeting. Take your time and get yourself in a good position to avoid potential issues.

Sometimes problems arise during a live demonstration, and this can cause the stakeholders to have an awful impression of the items created during the sprint. So, prepare yourself adequately. Conduct a mock presentation beforehand to make sure everything goes smoothly.

Another common mistake is to just use the sprint review as a status meeting. Instead of focusing on collecting feedback, these teams focus on progress instead. It’s important to track your progress, but this is not the moment for that. The sprint review is a time for demonstrating work and ensuring we’re on the right path.

Scrum teams often accidentally forget to invite some key stakeholders. If we are doing work for a specific user, we may find that they are not at the sprint review. How can we say that this is going to work for them?

Speaking of stakeholders, it is common for scrum teams to not engage them. They don’t ask these stakeholders questions or get them to speak more. So sometimes you just demonstrate your work, and everyone is quiet. You need to ask questions to get them more vocal and have them participate.

Finally, and probably the most common one: People may talk about other things in the review like how to make brigadeiro, I don’t know. Or maybe something related to the product but not on topic for the review like “I have a question about this item in the backlog. In the description.” You have to vocalize that the sprint review is not the time for these conversations.

You mentioned inviting all the key stakeholders, and that got me curious: How do you encourage the end-user to attend the sprint review? Is this ever a problem?

HR: It’s important to engage them. It can be hard but remind them that they are going to be using these functionalities, and it would be great if they could participate in this call to make sure that these will be useful for them.

Any other quick best practices you’d like to share?

HR: Keep focused on the sprint goal during the call. Don’t talk about brigadeiros [laughs]. You need to understand from the stakeholders if you have met the sprint goal.

Try to engage the stakeholders. It’s really an important moment to ask questions about the product, its future, and the market. It will help with planning the upcoming sprints.

Finally, make sure to celebrate! If you set a goal for the sprint and you achieve everything and receive great feedback, celebrate it. It really helps the team.

That’s crucial, absolutely. If you did something great, you need to take some time to celebrate it.  

HR: Yeah, yeah, it’s time to celebrate and finally eat brigadeiros [laughs].

Let us know how we can help you.