Massive feedback during the review - a sign of health or issues?
During one of the last reviews with one of my teams we had a bit less stakeholders and feedback than usual. We love the fact that many relevant (internal) people (some of them are also users) show up and share what they think, so I thought that during the retro, the team would be disappointed. That was not the case however and what one dev said “I do not think that less feedback was a problem. I think we presented our findings, data and feedback we already gathered in such a way that there was not a lot more to add”. This made me think, if focusing on a lot of feedback during the review is really a sign of building the product in an effective way or quite the opposite?
On one hand, feedback is always welcome, that’s the basic element of product development. We want to know more about what our customers need, what pain points they have, if our solutions serve them well.
On the other hand, the Reviews I’ve seen in many companies I worked for, do not give the team much of that. Usually those are opinions from internal stakeholders (not customers or users) about certain features that were delivered and what will be delivered next Sprint - a very project-driven style. Did we learn anything about our customers from that? Are we getting closer to the business goal? What are the business outcomes of that change? Those questions are often not even mentioned.
Even in the Scrum Guide, at least the current version, the Sprint Review section does not mention feedback: ” The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
领英推荐
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. [...]”
As you can read above, outcome and future adaptations are the important parts of the review, which I agree totally. The outcome however does not mean “features on production” - it can be feedback gathered from customers, data on what was put into production a month ago, released changes, their effect on infrastructure costs, etc. All of that can be accomplished during a Sprint, cause the change of environment (or our perception of environment e.g. customers needs) and will probably determine future adaptations. For example, we learnt that a small change on the payment step that we released a month ago caused a huge conversion drop, because customers feel “trapped”. This has probably nothing to do with releasing any new “features” in the last Sprint, but is crucial product information that will determine what we do next.
If you take a look at the Continuous Discovery process, that’s what product teams do - they verify assumptions, test hypotheses, look for customers' pain points, build solutions, look for opportunities, check how changes are doing, what has changed, what should be changed in the future and how. So assuming that you do all of these things, during the review (assuming you even do it) you come to your stakeholders with a lot of information, not only features - and this makes a lot of sense. Imagine finding a change in your customers behaviour that has an effect on the marketing campaign that is currently being developed. Noticing such things might not only affect your team, but everyone else in an organization. This can of course work the other way around, as you can also get informed about the changes that can affect the product, but I think such information should not wait until the review. In fact, both cases should not wait ;)?
To sum up, I think reviews are not about showing what cool features you did and getting feedback about them from CEOs or other stakeholders who in many cases have no idea how users are working with your product. It is about presenting your findings, business outcomes and validating how it affects what you are currently doing and what you were planning to do. You can also think even about skipping reviews, as all of that can in fact happen continuously - communicating all of that as soon as you get to know something new. What do you think?
Scrum Master, trainer
1 年What does "much feedback" mean? In most cases it is not just saying "We have no comments, everything as expected" in many ways. Usually rich feedback means a need for solid adjustments of our direction. If it happens constantly it could just be caused by high volatility of the business and market, but also can be a sign that we need to align long-term vision with our stakeholders (Product Goal, in Scrum terminology). Let's have some deeper conversation during Review to determine which case we are dealing with. On the other hand, getting hardly no feedback can be a good sign of "You did a great job and it's obvious". But can be also a very bad symptom of lacking real communication with stakeholders, maybe even an elephant in the room. Again, we can use some additional questions like "What is the most urgent area / issue the team should focus on in upcoming sprints?" So the answer to the question in the title is: It depends, clarify by further conversation.