We all know the world is not flat, and Scrum is not a linear process. But some Scrum teams use feedback only to improve the process, and forget to apply it to the product. User stories are consequently turned into software without learning from stakeholder feedback and adapting the backlog. This wastes a massive opportunity: to ensure that the right product with the right features is created. In this post, I discuss how Scrum’s cyclic nature helps you create a great product by running focused experiments.
A linear Scrum implementation transforms the highest-priority product backlog items into a product increment without feeding back the insights gained from exposing the software to the right people – users, customers, and internal stakeholders.
Such an approach assumes that the Scrum team already knows who the product is for, and what the product should look like and do. This may be appropriate for small incremental product updates with virtually no market and product-related uncertainty present. But it is insufficient for new products and bigger updates, where discovering how the user needs can be best met is a major challenge.
Scrum’s cyclic nature enables experimentation and learning: The product evolves based on the feedback of users, customers, and other stakeholders. Applied correctly, this results in a desirable product: a product that does a great job for its users. The risk of building something that nobody really wants is minimised. The following picture describes four key steps that help you iterate towards a great product.
In the first step of the cycle, product owner and team select a sprint goal that describes why the sprint should be run. At the early stages of a development effort, the sprint goal should focus on testing assumptions and acquiring the relevant knowledge.
Make sure you ask the right leap of faith questions and tackle the right area of uncertainty. Understanding your innovation drivers will help you do this. Once the sprint goal has been selected, the team develops the appropriate product increment.
In the second step, the product increment is exposed to the stakeholders. To do this, Scrum uses a product demo as part of the sprint review meeting. Alternatively, you can ask the users to test the product increment in the review meeting, or you can release the software and collect the relevant data.
In the third step, the Scrum team analyses the feedback and the data obtained. This includes reviewing the quality of the data, and assessing its relevance. Examining the data should help the team understand if a desirable product is being developed. But it does not mean saying yes to every idea or stakeholder request! Similarly, negative feedback should be welcomed. If all you get is positive responses, then you are likely to ask the wrong questions or the wrong people.
I am a big fan of involving the entire Scrum team in this step, product owner, development team, and ScrumMaster. This leverages the team’s collective knowledge, encourages shared ownership, and it mitigates cognitive biases – the risk of overlooking or misinterpreting data.
Finally, the Scrum team uses the newly gained insights to adapt the product canvas or backlog. This may result in big, radical or small, incremental changes depending on the sprint goal and the feedback received. If, for instance, the feedback invalidates the user experience approach chosen, bigger changes are probably necessary.
Then the next cycle starts.
Scrum defines a cyclic process that encourages learning and change. By exposing product increments to the right people, analysing the feedback, and learning from it, we maximise the chances of creating a successful product. If you currently don’t expose your product increments to the stakeholders regularly, then there is a great opportunity to improve your process and your product.
You can learn more about using Scrum to create successful products by attending my Certified Scrum Product Owner training course.
RSS
[...] Employing experiments is a powerful technique to facilitate the creation of new products and new features. [...]
[...] more here… Share this:EmailMorePrintDigg This entry was posted in Agile, Around the Block, Planning [...]
[...] Roman Pichler, “The Scrum Cycle” [...]
[...] Here is a drawing from Pichler Consulting. [...]