Photo by Min An on Pexels

The Product Backlog Refinement Steps

Published on 2nd April 2012 Last Updated on: 7 Mar 2022

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.

Ready User Story

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.

Post a Comment or Ask a Question


  • Edy Salim says:

    Hi Roman,

    Since I’m new to agile & scrum, I found your sharing very helpful for me to getting started with.

    I would like to know how to relate product backlog refinement steps and design thinking activities. At some point, I think they are pretty similar, especially product backlog refinement steps 1, 2, and 4, only that design thinking is more guided & structured.

    Thank you and my best regard from Jakarta.

    Edy Salim

    • Roman Pichler Roman Pichler says:

      Thanks for sharing your feedback and question Edy. Product backlog refinement is about discovering the right solution and making effective detailed product decisions. Design thinking is a much broader approach that covers product discovery elements. Hope this helps!

  • Lucy Jin says:

    Hi Roman, I heard that we’d better use backlog refinement other than backlog grooming. What do you think? Does it make a big difference? Please advice. Thanks.

    • Roman Pichler Roman Pichler says:

      Hi Lucy, Thanks of sharing your question. Product backlog refinement is the current term used by the Scrum Guide to refer to detailing, estimating, and prioritising the backlog. The traditional Scrum term is “grooming”. As both terms refer to the same set of activities, I recommend that you use the one that you are more comfortable with. Bear in mind, though, that analysing user feedback and applying the new insights may lead to larger changes in the product backlog that go beyond refinements and incremental enhancements.

  • Andreas says:

    Hi Roman! It’s me again 🙂

    I am having troubles to communicate to my three dev teams that grooming the product backlog is a shared responsibility. Their understanding is that the stories which enter the grooming session are already well prepared. Estimation is what is done in the grooming session. They demand other kick-off meeting to discuss stories in details and talk about how to solve them. Apparently, stories in the form of “As a user I want to do X so that I get value Y” is not enough specification to my dev colleagues.

    Maybe you have an idea how to bring business and engineering together in order to generate good PBIs.


    • Roman Pichler Roman Pichler says:

      Hi Andreas,

      I know this sounds like a cop out but the best advice I can give you is: Attend the next retrospective, and talk to the team about the issue. There could be many causes: Team members might feel they don’t have the time to contribute; the team members might have a wrong understanding of the product owner role; the team members may lack the knowledge or skills to contribute; or the team members might be worried that hey could be held accountable for the product’s functionality.

      Good luck!

  • Andreas says:

    Hi Roman, thanks for the simple approach. Seems that obvious that I did not think of it. The good thing is that it encourages to focus on value even in very technical stories. Regards from Hamburg!

  • Andreas says:

    Hi Roman,
    when we meet together in backlog grooming sessions, it is often the case that during discussion the teams realize that some refactoring is necessary. In the past that has lead to very technical user stories which were scattered all over the backlog. Since I became the PO, we are trying to reduce such “stories”. However, these things are necessary and I am having difficulties to organize them as user stories since the customer value behind such stories is often not clear to me due to the very technical domain. Do you have an advice how deal with refactoring and the like? The teams want to have an own backlog with such things. What do you think of that?

    Thanks a lot!

    • Roman Pichler Roman Pichler says:

      Hi Andreas, Thanks for your comment. I recommend that you add bigger refactoring items to the product backlog, as this creates transparency and facilities planning. For instance, you want to add new functionality but still meet your main performance constraint. The team has identified the database access layer as the main refactoring area. Now add the following refactoring item to your backlog: “Refactor the database access layer so that the user story ‘event management’ can be provided and the performance constraint ‘response time’ is still met.” Sometimes it makes sense to create a “Snow Leopard”, a maintenance release before new functionality is implemented by the way. If Apple can do it, so can we 😉

  • Praveen says:

    Hi Roman,

    Always glad to read your blog and book. I worked with you for a transformation work at EA. My scrum teams absolutely love the idea of grroming and it is part of thier DNA. I had few inputs to what happens in grooming and before planning.

    1. Spikes in grooming

    o Identifying/Discussing any needed ‘Spike’ PBI’s
     We like to identify these sooner rather than later because you generally want to do your ‘Spike’ PBI one or more Sprints before your “Follow On” PBI.
     Some of these may involve investigating new technologies that are architecturally risky
    o Identifying/Discussing external dependencies
     We like to identify these sooner rather than later because they make take multiple Sprints to resolve
     If the external dependency creates enough estimate uncertainty, you can also create ‘Spike’ PBI’s to get the external dependency resolved in an earlier sprint before the “Follow On” PBI in a later sprint.

    2. We have like champions within team who would voluteer to investigate this spike or do a quick prototype before the actual PBI’s are played next sprint.


    • Roman Pichler Roman Pichler says:

      Hi Praveen, Good to hear from you and thanks for sharing your experience. I’ve also found that spikes are helpful to explore different options particularly when dealing with a new feature of a mature product. If the spike is created in a different sprint compared to the actual story, it may be helpful to add the spike to the product backlog and make it high priority.

  • John Peltier says:

    Much of the agile literature de-emphasizes the work that goes into analyzing feedback. This gap is most apparent when agile is applied to off-the-shelf software rather than custom development.

    One way to mitigate that is mentioned in your post, but frequently not followed in these situations — bringing real customers into the sprint demos rather than just internal stakeholders. This is sometimes a difficult technique to sell, but an aggressive enterprise might find that an NDA could protect their interests while still deriving the benefit that this exposure provides.

    • Roman Pichler Roman Pichler says:

      Hi John, Thanks for your comment. You are right: Inviting real customers and end users to a demo can be a great way to get feedback. I’ve wanted to write a post on the different options to collect feedback for a while. Your comment makes me rethink my blog backlog prioritisation 🙂

Leave a Reply

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

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.