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
Collecting feedback from the right people is crucial to make the right product decisions: If you invite the wrong individuals or if key people are missing, then you are unlikely to receive the feedback you need. You should therefore make sure that you invite the right individuals.
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 individuals 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
More than one sprint review meeting I’ve attended was quickly over: A development team member demoed the functionality to confused looking stakeholders with the product owner in the background. Afterwards the ScrumMaster asked if there were any questions or feedback, but the stakeholders just looked at each other, a few said “nice job” and “looks good”, and then people left. The valuable feedback gathered in this meeting was zero.
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
Sometimes it’s helpful to split the sprint review meeting into two parts. First, you and the development team get together. The team demoes the product increment to you. Then you give feedback to the team members and determine which items are done and how much progress has been made using, for example, the release burndown chart (as I discuss in more detail below). If you decide to take advantage of just-in-time reviews where you provide feedback on new functionality during the sprint, you may not require this part at all.
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. But do make sure that the development team members attend the entire meeting and are present in the second part. Hearing feedback directly from the stakeholders is invaluable.
Consider Separately Collecting User and Stakeholder Feedback
The original idea of the sprint review meeting is to bring all the right people together and collect feedback from everyone at the same time. If that works for you, then that’s great. Often, though, I find that it is more helpful to separately gather feedback from users and internal stakeholders. Why? Both groups tend to have different perspectives and interests.
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
Sometimes, it’s possible to make product decisions straight away in the sprint review meeting and even change the product backlog, as the Scrum Guide suggests. But often—particularly if the feedback has a bigger impact and leads to significant backlog changes—you will benefit from having more time to analyse the feedback, draw the right conclusions, and determine which product backlog changes are required. Additionally, you may not have all relevant data available in the sprint review meeting if you decide to collect user and stakeholder feedback separately, as discussed above.
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
Imagine that all the feedback and data suggests that people are going to love your product. But if you are way behind schedule and over budget, then your product may not become a success—it may not even get officially released. It is therefore important that you regularly determine the progress made.
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.
| Published on Java Code Geeks with permission by Roman Pichler, partner at our JCG program. See the original article here: Sprint Review Tips for Product Owners Opinions expressed by Java Code Geeks contributors are their own. |
