A linear Scrum implementation transforms the highest-priority product backlog items into a product increment but it does not collect any user feedback to update the product backlog and consequently change the product, as the following picture illustrates:
Such a linear application of Scrum assumes that team already knows what the product should look like and do. This may be appropriate for smaller incremental product updates and maintenance releases. But this assumption does not hold true for new products and new features where discovering how the user needs can be best met is a major challenge.
To find out which user experience (UX) and which features the product should provide, a cyclic process that facilitates experimentation and learning is required: We only discover and learn new things by trying out an idea. Luckily, Scrum’s cyclic nature enables product owners and agile teams to learn about what to build and how to build it: 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, and it reduces the risk of building something that nobody really wants. The following picture describes three key steps that help you iterate towards a great product.
The diagram above is inspired by Eric Ries’ Lean Startup circle. You can find out more about how Lean Startup and Scrum can fit together in my post “New Product Development with Lean Startup and Scrum“.
Step 1: Select the Sprint Goal and Create the Increment
In the first step of the cycle, product owner and team select a sprint goal that describes why the sprint should be run and what the desired outcome is. At the early stages of a development effort, the sprint goal should focus on testing critial assumptions and acquiring the relevant knowledge. These include assumptions about the user interaction, the product functionality, the visual design, and the technologies and the architecture. You can download a handy sprint goal template that facilities experimentation from the tools section of my website.
Once the sprint goal has been selected, the team develops the appropriate product increment. This could be a throw-away prototype (such as a paper prototype or a spike) or working software that can be released —depending on what’s best to meet the sprint goal. A paper prototype might be best, for instance, to test assumptions about the user interactions (“Are users willing to register first before they use the main features?”); a throwaway mock-up may be appropriate to test user interface ideas (“Will corporate colours resonate with the target group?”), and a software increment will help to run a more in-depth usability test or to release the product to selected users to run an A/B test, for instance.
Step 2: Gather Feedback and Data
In the second step, the product increment is exposed to the stakeholders and feedback or data is collected. Scrum’s default technique is a product demo which is performed as part of the sprint review meeting. But you can of course also run a usability test or release the software to collect the relevant data. As a rule of thumb, use different methods across the development cycle and combine qualitative and quantitative techniques.
Step 3: Analyse and Change
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! Having said that, you should welcome negative feedback. If all you get is positive responses, then you are likely to ask the wrong questions or the wrong people. (For more information please see my post “Data Analysis Tips for Product Managers and Product Owners“.)
Finally, the Scrum team uses the newly gained insights to adapt the product backlog. This may result in bigger or smaller changes. If, for instance, the feedback invalidates the user interaction design, bigger changes are likely to be required. The earlier you are in the process of creating a new product or new features, the more likely it is that your product backlog changes significantly. Once you have addressed the key risks and critical assumptions in your backlog, smaller changes or refinements are usually sufficient. (I have written more about this in my post “Learning and Execution in Scrum“.)
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, you can maximise the chances of creating a successful product. If you currently don’t expose your product increments to the stakeholders on a regular basis, then there is a great opportunity to improve your process and your product.
[This post was updated on 27 March 2014.]