Option 1: In the Sprint Review Meeting
Your first option is to work on the product backlog in the sprint review meeting. Assuming that the development has developed a “done” product increment and the right people are present, you can use the attendee’s feedback to make the relevant product decisions and update the backlog, as the Scrum Guide suggests and the following picture shows.
This approach ensures that the backlog is updated before the next sprint starts. This allows you to immediately action any new insights thereby mitigating the risk of taking the product in the wrong direction. Additionally, the backlog is collaboratively worked on. This creates strong buy-in from the people participating in the sprint review meeting.
But it only works if the attendees are able to provide relevant feedback, are willing to collaborate and can quickly agree on the necessary backlog changes. What’s more, the feedback must not require further analysis or give rise to bigger backlog changes. Don’t use this option if a significant amount of uncertainty and change is present in your product backlog, for example, if you work on a new product or extend your product’s life cycle.
Option 2: In a Separate Workshop Prior to Sprint Planning
Your second option is to have a separate product backlog workshop prior to the next sprint planning meeting. The workshop should include you as the product owner, the development team, and the ScrumMaster. Collaboratively analysing the data and working on the backlog, mitigates the risk of drawing the wrong conclusions due to cognitive biases; it leverages the creativity and knowledge of the team, increases understanding and buy-in, and leads to better requirements.
As the picture above illustrates, my preference is to hold the workshop right at the beginning of the next sprint. This violates the Scrum rule that the sprint planning meeting must be the first event in every sprint. But it allows you to respond to the feedback in the subsequent sprint without rushing or dropping the sprint retrospective or working late or at the weekend. What’s more, it provides the benefit of separating the data collection from the analysis: It allows you to review the feedback without the people present who provided it. It also give you more time to assess the feedback, derive the right insights, make the right product decisions, and change the product backlog accordingly. This makes it easier to deal with difficult feedback and requests, and to carry out bigger product backlog changes.
Note that this approach still assumes that you can collect the relevant feedback in the sprint review meeting, for instance, by carrying out a product demo, usability test, or solution interview. If you decide to release the product increment to (selected) users, then it is unlikely to work for you, as collecting the relevant data often takes several days in my experience. Take a look at the next option instead.
Option 3: In a Separate Workshop After Sprint Planning
If you validate your product decisions by releasing software to (selected) users, then option three may suit you. It suggests that you hold a product backlog workshop involving the development team and ScrumMaster after the next sprint planning has taken place, as the picture below shows. This approach assumes that you require several days to gather the relevant user data before you can analyse it and make the appropriate backlog changes. It also assumes that you don’t have to wait for the data to arrive to decide on the next sprint goal. Instead, you can continue with the next sprint while collecting the data.
While option three allows you to validate your product quantitatively, it too has a drawback: As sprints are protected, the earliest point in time you can respond to the backlog changes is sprint+2. It is therefore advisable to start with option one and two, and use option three once the crucial risks in the backlog have been addressed. Additionally, you should focus on a different feature in sprint n+1 compared to sprint n in order to avoid the danger of building on wrong decisions.
Option 4: Continuously
If you don’t need to wait until the end of the sprint before you release a new or improved piece of functionality, then option four is for you: You continuously collect data, analyse it, and change the backlog accordingly. You may want to set a side 30 minutes every morning to look at the latest data and draw the right conclusion from it, preferably with the help of the development team or some of its members.
Note that option 4 assumes that you either make small incremental improvements to a product or that you run multiple overlapping experiments to test ideas for new or improved features, for example, by releasing feature fakes or MVFs.
Strictly speaking, Scrum is not well suited to support this approach. The model assumes that a cross-functional development team has to work together for several weeks to achieve a shared sprint goal and deliver a product increment. A sprint is intended to run one experiment or implement related product functionality. It’s not particularly well suited to execute multiple tests and continuously release smaller enhancements and bug fixes. You might therefore consider changing from Scrum to a Kanban-based process, as I discuss in more detail in my post Is Scrum Right for Your Product?.
Learn More
I hope that this article has helped you clarify your understanding when you should work on the product backlog, particularly to validate ideas and translate new insights into backlog items.
| Reference: | Tips on When Product Backlog Grooming should Take Place from our JCG partner Roman Pichler at the Pichler’s blog blog. |
