Sprint Review Tips for Product Owners

Photo courtesy of Pexels

The sprint review meeting is maybe the most important Scrum event for product people — it helps you collect feedback and make the right product decisions thereby increasing the chances of creating a successful product. But I find that product owners are not always clear on who should attend the meeting, how it should be run, and how to collect the relevant feedback. This article answers these questions and shares my tips for getting the most out of the sprint review.

Involve the Right People

As a rule of thumb, ask those people to attend whose input you need to validate the latest product increment and move the product forward. These are typically your key stakeholders — the people who have an interest in your product and who you need to develop and provide the offering. These may include people from marketing, sales, service and support, and other business units depending on your product and organisation.

I find it helpful to explain to the people you invite why they are asked to attend the meeting and what they are likely to see in order to encourage them to participate and to set their expectations.

Collaborate but Don’t Be Afraid to Say No

Therefore, encourage people to actively participate and share their views, ideas, and concerns. Use open-ended questions like “What do you think about the improvements we made to registration feature?” Try to understand why somebody likes or dislikes the product increment. Receiving feedback such as “looks great” may feel good, but it does not offer any new insights. Why does the person like the changes? And is there anything that could be improved further?

Give all attendees the opportunity to be heard. Appreciate their opinions and feedback, even if you disagree or find it difficult to accept them. Remember: The creativity, knowledge, and feedback of the stakeholders should help you make the right product decisions and offer the best possible product.

At the same time, don’t accept that individuals use the meeting to make demands or strike the best possible deal for themselves or their business units. I remember one sprint review meeting where a senior stakeholder literally shouted his demands at the product owner and dev team — which was neither appropriate nor helpful, of course.

As the person in charge of the product, be kind and understanding. But do not let the stakeholders tell you what to do. You own the product and you must have the final say — otherwise you don’t have enough authority and respect.

Don’t be afraid to say no to ideas and requests if they are not helpful and realistic. Use the product roadmap together with the overall product strategy to decide if you should take on a request. In doubt, use the next sprint to test if the idea or request would be beneficial to the users. But remember that it’s virtually impossible to offer a product that pleases everyone.

Ask your ScrumMaster to facilitate the meeting and establish ground rules. This allows you to engage with the attendees and collect feedback without having to moderate.

Consider Splitting the Meeting in Two Parts

In the second part, the stakeholders join the meeting. I find that as the product owner, you are often best suited to present the product increment to the stakeholders: You are likely to better understand how a user would interact with the product and use the new functionality than a development team member. Then collect feedback from the stakeholders to understand if you are creating the right product with the right user experience and features. Ask open-ended questions as recommended above in order to understand why the new functionality is great or why it should be changed, for example.

Splitting the meeting allows you to have a private conversation with the dev team and possibly sort out any disagreements before people from outside the Scrum team join you. This is particularly helpful when you didn’t have the chance to interact with the team during the sprint — be it that you are not collocated with the team or that you were busy visiting users and customers or attending a tradeshow or conference.

Consider Separately Collecting User and Stakeholder Feedback

Testing product increments with users allows you to understand if the product is likely to do a great job for its target group, if it offers the right user experience and the right features. Discussing increments with stakeholders helps you understand if the product be effectively offered, if it can be operated, marketed, sold, and supported by your organisation.

What’s more, it’s best to collect the user and stakeholder feedback using different techniques: Demoing the product increment to end users makes sense when very little functionality has been implemented. Otherwise, it tends to be more helpful to observe or measure how people actually use the product employing, for example, usability tests and early releases. (See my article “How to Choose the Right Product Validation Technique in Scrum” for more information.)

As these techniques usually require more time than the sprint review meeting offers — it may take several days to collect the relevant data after you’ve released a product increment to (selected) users — this naturally separates collecting the user data from gathering stakeholder feedback.

Bear in mind that users trump stakeholders: If the product is not beneficial to the users, people are not going to employ it (for long), no matter how sellable or serviceable it is, or how much the CEO loves it.

Don’t Decide Hastily

You should therefore consider separating collecting feedback and data from analysing and actioning it. You may choose, for instance, to have a short, focused product backlog workshop prior to the next sprint planning meeting that offers you the opportunity to objectively evaluate the feedback and update the backlog together with the development team; or you may want to schedule a product backlog session in the next sprint once you have collected enough user data with the help of an analytics tool, as I explain in my article “When should Product Backlog Grooming Take Place?”.

Discuss the Release Progress

The sprint review meeting is a great opportunity to do this, as you should now be able to tell which items were completed and therefore understand how far you have come. Additionally, the key stakeholders who attend the meeting have an interest in finding out if the new product (version) will be released as planned or if there is a delay, as this is likely to impact their work. What’s more discussing the progress puts the current sprint into context and connects it with the previous ones.

I like to work with the release burndown chart, Scrum’s standard artefact for tracking the release progress and anticipating how the project is likely to unfold. The chart shows how the effort in the product backlog develops from sprint to sprint — the idea being that the effort is reduced or “burned down” over time.

No matter which tool you use: make sure that it helps you understand how fast you are progressing and to make the necessary adjustments — be it adding a UX designer to the team, postponing the release date, or partially meeting the release goal and possibly delivering fewer features than planned.

Learn More

Product management expert. Author of “How to Lead in Product Management”, “Strategize” and “Agile Product Management with Scrum”. www.romanpichler.com