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 effective 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. Attentively listen to them and 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 Scrum Master 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 Development 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 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, understand how far you have come, and if you are on track to meet the product goal on as expected. This information is also valuable for the key stakeholders who attend the meeting so that they can adjust their work if required. 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 development progress and anticipating how the development effort 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, partially meeting the product goal and possibly delivering fewer features than planned, or pushing out the release date.
Post a Comment or Ask a Question
6 Comments
Hi Roman, I have faced a scenario where a few ‘difficult’ characters in the Scrum team want to use the sprint review meeting as means of ‘confirming’ whether a particular user story, spikes etc are indeed done or not. This has now meant that we do not close the sprint until after the sprint review has taken place. Also, all the various user stories, spikes, enablers etc all have acceptance criteria documented and understood, yet we have now resorted to ‘agreeing’ whether an item can indeed be marked as done during the sprint review meeting. I have pushed back but to no avail and wanted to get your perspective on this please.
Thanks for sharing your question Javed. In Scrum, the product owner determines if an item is done using the definition of done and, if user stories are used, the stories’ acceptance criteria. If other Scrum team members repeatedly disagree with the product owner, then investigate in the next retrospective why this is. Is the definition of done not clear? Is it too weak or too ambitious? Or is the role of the product owner not properly understood? Your Scrum Master should be able to help you with this issue. Good luck!
Many thanks for coming back Roman. The only clarification I’m looking for is it good practice to hold the sprint review and use that forum to move stories to done. My experience tells me to use DoD and ACs to close stories and then demo what has been completed in the sprint review; not to use it as a forum to close stories and only end the sprint after the sprint review meeting.
You’re welcome Javed. The sprint review meeting provides a good opportunity to determine what is done and how much progress has been achieved–as well as to collect feedback from (selected) users and customers and the stakeholders. The product owner may review backlog items just in time as they get done in the sprint if this works for the Scrum team. The development team should demo only items that the members believe to be done. Hope this helps!
One project is on a two week sprint cycle. At the end of the sprint, they demo to the product owner. 4 days later they demo to a set of stakeholders the same thing… in the meantime the scrum team have started on the next sprint without adding the new requests to the product backlog / reprioritizing it. The stakeholders then have additional requirements that may or may not find their way into the product backlog until the 3rd sprint assuming the product backlog has now been groomed.
Question: What the team is doing – demo to PO and then 4 days later demo to other stakeholders while the Scrum team is on its second sprint – is this a good practice and should it continue? And how does one account for the lag in documenting the user stories.
Thanks for sharing your question, Manisha. How important it is to immediately validate a product increment and the related product decisions, depends on the amount of innovation and uncertainty present. When you build a brand-new product or create a major update of an existing one, having a lag between finishing the product increment and receiving feedback/validation is undesirable, at least in the first few sprints of the development effort, as this might result in the dev team heading down a wrong path. But once you have addressed the major risks in your product backlog, such a delay is usually not a big issue. (I discuss different options to gather feedback and update the backlog in the article “When Should Product Backlog Grooming Take Place“.)
Having said that, I would be interested to understand what it would take to have the stakeholder feedback in the sprint review meeting. It would be helpful for the dev team members to witness the stakeholders’ reaction to the new increment and directly hear their feedback. Additionally, don’t forget to regularly collect user feedback and data. The users of your product ultimately determine its success, not the stakeholders.
Hope this helps!