How Can Scrum Be Applied to Develop and Improve a Customer Feedback System Like Kroger’s?
Iam part of a team working on creating a customer feedback system inspired by Kroger’s survey platform. The goal is to collect user feedback efficiently and implement changes based on their input. We are using Scrum to guide the development process but are looking for advice on a few challenges:
- How do we prioritize feedback-related user stories in the product backlog to ensure the most valuable features are delivered first?
- What’s the best way to incorporate continuous customer feedback into Sprint Planning and Reviews?
- Are there any specific Scrum practices or tools you recommend for managing a project with frequent user input?
If you have managed similar projects or have tips on how to align Scrum events and artifacts with customer-driven workflows, I’d appreciate your insights. Thank you!
How are you measuring and correlating actual customer behaviours to survey data? Perhaps empirical evidence of that nature, gathered in real time and with minimal filtering and delay, ought to shape value and prioritization. What customers appear to say and what they actually do are not necessarily the same thing.
You receive frequent feedback, but what is the mechanism that you determine which feedback is more valuable or important than others? It seems your problem lies here, as @Ian mentioned
Throughout the sprint changes can be made to the product backlog (PB) as feedback cones in. Add proper feedback as a PB item. Order the Product Backlog according to priority, but this is done by the Product Owner depending on value and the product goal (possible in collaboration with the team and stakeholders). During planning items can be discussed and further refined, but to select items pull from the top of the Product Backlog.
I agree with @Ian's comments about what people say does not always match what people do. You also have to remember that most feedback is given by people that are not happy but that does not mean that they are the majority.
When dealing with feedback from a system of the type you describe, you have find ways to validate the input. You also have to find ways to make sure that the positive feedback is taken as seriously as the negative. From my experience a good and experienced person with a background in defining products based upon market demand can usually take this into consideration. The Scrum Guide describes accountability for that type of individual as the Product Owner.
If you have managed similar projects or have tips on how to align Scrum events and artifacts with customer-driven workflows, I’d appreciate your insights.
The project you are describing is maintaining a software product. It is no different than any other software product that has a long life. You are trying to make this too difficult. You take the input you are receiving, validate it, use it to build the contents of the Product Backlog, and continue development of the Product by incrementally delivering valuable updates to the stakeholders. If the continuing feedback indicates additional changes, then you make additional changes. This continues until the decision is made to remove the Product from availability.