Sprint Review: Getting Real Stakeholder Feedback
The Sprint Review is more than a demo. It is a critical event for inspecting the Increment and gathering feedback from stakeholders. This direct interaction fuels adaptation.
The Sprint Review is a working session. It is not a status meeting. It is not a formal presentation. It is an opportunity for the Scrum Team and its stakeholders to inspect the Increment and adapt the Product Backlog. This direct interaction is fundamental to Scrum's empiricism. Without it, the team works in a vacuum. They build what they think users need, not what users actually need.
Why Stakeholder Feedback Matters
Feedback is data. It tells you if you are building the right thing. The Scrum Guide is clear: the Sprint Review's purpose is to inspect the outcome of the Sprint and determine future adaptations. This requires active participation from stakeholders. They are the ones who use the product or are affected by it. Their input is invaluable. Ignoring it means building features that go unused, wasting time and resources.
Real feedback means honest, critical input, not just polite applause. It means stakeholders asking questions, suggesting changes, and pointing out what does not work for them. The Scrum Team needs to create an environment where this kind of feedback is welcomed and encouraged. This is how the product evolves effectively.
Who Should Attend
The entire Scrum Team attends: Product Owner, Developers, and Scrum Master. Beyond that, the Product Owner invites key stakeholders. These are the people whose input truly matters for the product. This could include users, customers, business managers, or even compliance officers. The goal is to get a diverse set of perspectives. Too many people can make it unwieldy. Too few means missing critical viewpoints. The Product Owner makes this call, ensuring the right people are present to provide meaningful feedback on the Increment.
Making the Increment Inspectable
The Increment shown at the Sprint Review must be done. It means usable. It means it meets the Definition of Done. It is not a partially completed feature or a mock up. It should be a tangible piece of working software or a functional component. This allows stakeholders to interact with it directly. They can click buttons, enter data, and experience the new functionality as if it were already released. This hands on interaction drives better feedback than looking at slides or screenshots.
If the Increment is not truly done, the feedback will be speculative. Stakeholders will comment on potential functionality, not actual functionality. This undermines the entire purpose of the review. The Developers are responsible for producing a done Increment each Sprint. This is non negotiable.
Facilitating Productive Feedback
The Product Owner explains what has been done and what has changed in the Product Backlog. The Developers demonstrate the Increment. This demonstration should be brief and focused on the value delivered. After the demonstration, the floor opens for discussion. Here are some ways to encourage effective feedback:
- Ask open ended questions. Avoid yes or no questions. For example, instead of 'Do you like this?', ask 'How does this new feature help you achieve your goal?'
- Encourage stakeholders to use the Increment themselves. Let them click around. Observe how they interact with it.
- Record feedback directly. The Product Owner should capture all input. This includes praise, concerns, and new ideas.
- Focus on the 'why' behind suggestions. Understand the problem a stakeholder is trying to solve with their proposed change.
- Remind everyone that the Product Backlog is a living artifact. Feedback will influence its future state, but not everything can be implemented immediately.
The Product Backlog as an Outcome
The primary output of the Sprint Review is a revised Product Backlog. Based on the feedback, market conditions, and potential new insights, the Product Owner adjusts the Product Backlog. This might mean reordering items, adding new ones, or even removing some. The Sprint Review is the formal opportunity for the Scrum Team to collaborate with stakeholders on what to do next. It is how the product strategy adapts to reality. Without this adaptation, the team risks delivering something nobody wants or needs. The Sprint Review ensures the product remains valuable and relevant.