Things to know about Product Backlog Refinement

In order for a sprint to be planned and work to begin in Scrum, the product backlog must be well maintained and filled with appropriately prepared product backlog items. It is logical that the backlog must be refined on a regular basis - but how does that actually work? 

In this article, we will show you exactly what Product Backlog Refinement means, what you should pay attention to and why refinement is so important.

What is the Product Backlog Grooming or Refinement im Scrum?

Until a while ago, product backlog refinement in Scrum was called backlog grooming. Backlog refinement is about maintaining and preparing the product backlog with its items and epics so that the Scrum team can use it as a basis for sprint planning.

Product Backlog Refinement therefore means: The Product Backlog items are elaborated, evaluated and prioritized in such a way that the Development Team can compile its Sprint Backlog from them. A maintained product backlog should always contain at least as many prepared product backlog items in stock that can be used to plan a complete sprint.

The overall goal of backlog grooming is to ensure that the development team understands the product vision of the product owner and the user stories he or she has created, and is thus able to plan the next sprint according to the sprint goals.

By the way, if you look up the term Refinement in the Scrum Guide, you will find that it is not one of the official Scrum events or occurrences such as Sprint and Daily Scrum. Rather, the Product Backlog Refinement is a so-called activity that takes place as a meeting. In addition to the product owner and the development team, the Scrum master and - especially in the case of strategic refinements - stakeholders take part in the refinement meeting.

This is how the Backlog Refinement Meeting works

Before the actual backlog refinement, there is the preparation:

• The Product Owner sets the goal of the Sprint (Outcome).
• According to this sprint goal, the PO prioritizes the product backlog and selects the most important product backlog items (PBIs) or writes new ones.
• The Scrum Team jointly formulates a Definition of Ready (DoR), which defines which characteristics or which level of detail these Product Backlog Items must have so that the development team can include them in a Sprint.

Now it is time to conduct the Backlog Refinement Meeting:

• The product owner and the development team discuss the sprint goals and the associated PBIs. It is important that the PO only communicates the goal to be achieved and does not specify how it should be achieved.
• The development team provides input. This includes their own ideas for implementation, based on their knowledge of the application or product, on the one hand, and comments on technical dependencies between the PBIs, on the other, whereupon some topics are still reprioritized.
• As soon as the development team and PO have reached a common understanding of a Product Backlog item, the PO or a team member documents this PBI according to the DoR formulated in point 3 and notes acceptance criteria, for example. Many teams also perform effort estimation at this point - they then call it Estimation Poker rather than Planning Poker, since it does not take place in

Why is the Product Backlog Refinement (Grooming) neccessary for success?

A good product owner takes refinement very seriously. He knows that regular and serious backlog grooming lays the foundation for the course of the subsequent sprint and thus for the success of a product, because:

• Refinement ensures that the Product Backlog is up to date and can be used as a basis for the next Sprint Planning.
• This type of preliminary work allows the development team to deal with the most important PBIs at an early stage and to ask questions that would otherwise only arise during Sprint Planning. This gives the PO the opportunity to find the answers in time for the Planning Meeting.
• The Sprint Planning meetings become shorter, because now only the "how" of the implementation has to be discussed, since the "what" has been clarified by the refinement. In addition, the PBIs have ideally already been estimated by the team and can be drawn according to velocity. This avoids that not enough prepared PBIs are available in Sprint Planning.
• By dealing with the PBIs together, the PO and the development team develop a common understanding of the vision, goals and tasks more quickly.all ideas of the development team for the implementation of a PBI are noted in it in the Refinement.
• There is a tremendous transfer of knowledge as the PO gives the team more and more context about customers, business model, etc. through the Refinement.
• In the sprint, the team can focus more on the actual work, because the most important questions were clarified in the refinement.

This is what you should keep in mind during Product Backlog Refinement!

• Before you can finally prioritize or order the PBIs in the Product Backlog, you should have a feeling for the scope of the individual items, because this determines the costs, which in turn influence the priority. In Scrum, scope is estimated in relative units of measure such as Story Points.
• Scrum does not specify when and how often you have to do the Product Backlog Refinement. Our recommendation for this is: 1 x per week e.g. in the middle of the sprint. Some teams perform daily and shorter Refinements instead, which mainly depends on the availability of the Product Owner.
• As with events and other activities in Scrum, it is also recommended that Product Backlog Refinements be performed regularly according to a fixed rhythm so that a routine develops.

Conclusion on Product Backlog Refinement

A regular and clean Product Backlog Refinement is absolutely essential for a successful Sprint - and thus for the success of the product. If you are already working as a product owner or would like to prepare for this exciting role and practice product backlog refinement, we would be happy to support you with a suitable product owner training.