Photo by Jamison McAndie, courtesy of Unsplash

The Scrum Cycle

Published on 21st September 2012

Scrum is a simple framework based on the idea of inspect and adapt: Create a product increment, show it to the stakeholders, and use the feedback to see if the right product is developed. This post describes what I regard as the essence of Scrum: a cyclic three-step process. It shows how the three steps help create a product with the right features and the right user experience (UX).

Linear Scrum

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:

Linear Scrum

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.

Cyclic Scrum

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 Scrum CycleThe 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.]

Post a Comment or Ask a Question


  • John Austin says:

    In the 1st step of this page “Select the Sprint Goal and Create the Increment”, you mentioned

    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 .

    What do you mean by this?

    • Roman Pichler says:

      Thanks for sharing your question John. An example of a user interaction assumption for a healthy eating product would be that users are willing to share personal information like gender, age, weight, and dietary requirements before they start using the app. If this assumption turned out to be wrong, then users might not engage with the app. It would therefore be advisable to validate the assumption and select an appropriate sprint goal, for example, “Test that people are willing to share personal information before using the main features of the app”. Does this help?

  • Nick Zdunic says:

    I just did some ATERN training. It tries to implement feedback by having an exploration phase at the beginning of the timebox. this is followed by engineering to harden the solution after getting the feedback. It has merits and could make for an interesting burndown chart if using points.

5 Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *