Refining the product backlog helps you make the right product decisions and get the product backlog ready for the next sprint. In this post, I show how you successfully refine your product backlog in five steps.
Step 1: Analyse the Data
Refining the product backlog starts with analysing the feedback and data collected from exposing a product increment to target users and customers. The increment may be working software, or in the case of a brand-new product, a paper prototype. The data obtained may be quantitative, qualitative, or both depending on the validation technique used. I prefer to work with both, qualitative and quantitative data whenever possible and combine, for example, direct observation with A/B tests.
When evaluating the feedback, focus on the data that is relevant to help you understand if you are building the right product with the right UX, features, and technologies, or how you can further enhance and optimise the product. Have the courage to say no to new ideas and requests if these are not helpful to meet the current product goal. Otherwise, your product is in danger of becoming a feature soup, a loose collection of features with little or no connection.
Be aware of the cognitive biases we all have, your hidden assumptions and wishes, as these can lead to ignoring or misinterpreting data. Example biases are confirmation bias, the tendency to prefer data that confirms our preconceived ideas and views, and anchoring bias, the tendency to rely too much on the first piece of information obtained. To mitigate the risk, analyse the feedback together with the development team members.
Finally, remember that negative feedback is good feedback: If all you ever hear is positive, you don’t learning anything new and you miss opportunities for making your product even better.
Step 2: Integrate the Learning
Once you have analysed the feedback, draw the right conclusions and incorporate them into the product backlog. This usually results in removing, adjusting, and adding items, including epics, non-functional requirements, design and workflow sketches.
But you might also find that the product goal you are pursuing is no longer valid or feasible within the time and budget constraints. If that’s the case, you may have to adjust not only the product backlog but also the product roadmap, assuming that you use such a plan.
Step 3: Decide what to do Next
After incorporating the new insights into your backlog, decide what to do next and choose the right sprint goal. Ask yourself what needs to be done next and what the purpose of the next sprint is. Which ideas and assumptions do you want to validate, which risks do you need to address? Or which functionality do you want to provide or enhance? You may want to try my sprint goal template to capture goal.
Step 4: Refine the Backlog Items
Next, break the larger items that help you to reach the sprint goal into smaller. For example, break epics into user stories. Then make them high-priority, and order the items according to their importance for reaching the sprint goal.
You may also want to ask the development team to estimate any epics that have been added or adjusted as well as the newly formed stories. This allows you to understand how much effort is roughly contained in the backlog, to prioritise by cost-benefit, and track the development progress, for example, by using a release burndown chart.
Step 5: Get the High-Priority Items Ready
With small, ordered user stories in place, you are close to starting the next cycle. But before you do so, ensure that the stories are ready: clear, feasible, and testable. This may entail creating a user interface design sketch and one or more operational quality constraints for the stories, as the picture below illustrates.
Getting the stories ready may also require resolving dependencies between teams if several teams work on the same product. The stories should now be ready to be pulled onto the sprint backlog or the Kanban board.
Product Backlog Refinement is Teamwork
When I talk to Scrum product owners about refining their product backlogs, it’s not uncommon for me to discover that the individuals carry out the work on their own. This wastes a massive opportunity: to mitigate the product owner’s cognitive biases, create shared ownership of the product backlog, and leverage the team’s collective creativity and knowledge.
As the product owner, involve the team members in the refinement work. This reduces your workload, and it is likely to result in better requirements and a better product. Don’t be afraid, however, to facilitate the discussions and to make a decision if no consensus can be reached. You don’t want to get stuck in analysis-paralysis but move on, and test new ideas or deliver more functionality.
