When should Product Backlog Refinement Take Place?

A refined product backlog facilitates the development of a successful product: It incorporates new insights and learning, and it provides items that are ready to be implemented. But when should you work on the backlog? Before the new sprint starts or afterwards? And how can you decide which option is appropriate? In this post, I discuss four options with their benefits and drawbacks to help you make the right choice.

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 product 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 product 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 Scrum product owner, the development team, and the Scrum Master. Collaboratively analysing the data and working on the backlog, mitigates the risk of drawing the wrong conclusions due to cognitive biases like confirmation bias; 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 enables 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 this option is unlikely to be appropriate for you, as it often takes several days to collect the relevant data in my experience.

Option 3: In a Separate Workshop After Sprint Planning

If you validate your product decisions by releasing software to (selected) users, then this option may suit you. It suggests that you hold a product backlog workshop involving the development team and Scrum Master 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 different features in sprint n+1 compared to sprint n in order to avoid the danger of continuing to move your product in the wrong direction.

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 you will benefit from continuously collecting data, analysing it, and changing the product 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 works 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 to 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 article “Is Scrum Right for Your Product?“