The sprint demo is a standard technique in Scrum to collect feedback from users, customers, and stakeholders in order to maximise the chances of developing a successful product. Sadly, not all product demosI have attended were effective. This article provides ten practical tips to fully leverage product demo, collect helpful user feedback, and make the right product decisions.
Understand the Purpose of the Product Demo
In Scrum, the latest product increment is demoed to users, customers, and stakeholders in the sprint review meeting. While the product demo allows you to understand which stories have been completed and how much progress has been made, using it as a qualitative market research technique unleashes its real potential. Its main purpose is then to collect feedback from the meeting attendees to validate the product decisions taken and improve the product.
Focus on the Sprint Goal
Understand what questions you would like to get answers to, and what ideas you would like to validate before conducting the demo. Your sprint goal should help you with this: If, for instance, your sprint goal is to test your user interface design ideas, then you should plan the demo accordingly. You may want to present different versions as mock-ups to the users to understand which one they prefer and why that’s the case. Having one sprint and research goal helps you focus the presentation. It increases the likelihood to collect relevant feedback, and it makes it easier to analyse the feedback.
Invite the Right People
Use your sprint goal to decide who can help you validate your ideas and improve the product and who should therefore attend the demo. If the goal of the sprint is to establish the right software architecture decisions, then end users are probably not the right attendees. In the worst case, the demo could be a frustrating experience and prevent them from attending another review meeting. But if the goal is to better understand how users are likely to interact with the product, then end users should be present. Otherwise, you are in danger of collecting lots of interesting but irrelevant or misleading data.
Explain what the Product does for the Users
To receive helpful feedback, describe what the product does for its users. A great way to do this is to use a scenario. If you develop a mobile banking application, for instance, you may want to say: “Imagine you are on the train on your way to work, and you remember you still need to pay your water bill. You open the banking app, log on, and then you would see the screen I am showing you now.”
Engage in a Dialogue and Ask Open Questions
The product demo should not be a one-way communication or a sales event. Instead, its objective is to generate valuable feedback that allows you to gain new insights. Unfortunately, users and other stakeholders don’t always provide helpful feedback straight away. You sometimes have to ask the right questions and create a dialogue. For instance, if the feedback you receive is “Great demo, I really like the product”, then that’s nice. But what does it actually mean? How does it help you, and what can you learn from it? Dig deeper, ask why the individual likes the product, which aspects are particularly valuable, and which could be improved. Using open questions is a great way to do this. You might say, for example: “Thank you for the feedback. Can you please tell why you like the product? Is there a specific aspect that makes it particularly valuable?”
Appreciate Difficult Feedback
It can be tempting to seek positive feedback that confirms the decisions you have taken and appreciates the hard work you put in. But if you don’t hear critical feedback, you’ll find it hard to improve your product. Therefore appreciate negative feedback and try to understand the underlying causes, for example, why somebody dislikes a feature or disagrees with the way a user journey is realised. Watch out for confirmation bias, the tendency to look for data that confirms preconceived ideas. I find that the longer we work on a product, the more we tend to become attached to it, and more likely it is to suffer from confirmation bias.
Capture the Feedback
To be able to evaluate the feedback afterwards, I recommend you record the feedback you receive, be it by videoing the demo together with the attendees reactions or by taking notes.
Separate Research from Analysis
I prefer to separate collecting the feedback from analysing it. This allows me to listen to the users, and to decide afterwards what I can learn from the information gathered. It also makes it possible to compare notes with the team members thereby leveraging the collective wisdom of the group and mitigating cognitive biases, think of confirmation bias, which I mentioned above. But I do recommend that you reject an idea or request immediately if you know that it is not in line with the product goal chosen or that it is not beneficial for the majority of the users. Have the courage to say no. Don’t allow powerful stakeholders to put you under pressure and make you commit to a request.
Ask the Scrum Master to Facilitate
Facilitating the sprint review meeting and at the same time, collecting feedback can be challenging. I therefore recommend that you ask your Scrum Master to ensure that everyone is heard, and that nobody dominates, especially when you have a larger or diverse group of people present.
Understand the Limits of the Product Demo
A product demo is a great tool for getting feedback particularly in the early sprints when the product has not enough functionality to be exposed in other ways to the users. But it does have a drawback: Users provide feedback based on what they see and hear. The demo does not validate how people actually use the product. I hence recommend you employ user tests and software releases once your product has progressed far enough. This allows you to understand better how the users interact with your product, and how well your product meets their needs.
Post a Comment or Ask a Question