How to conduct a Product BackLog Refinement

Often called grooming, but the translation from English is rather strange, so the wording Refinent is left in the Scrum Guide.

The goal is to prepare for planning so that all stories are valued or re-evaluated. For example, if planning on Monday 27th January is Monday, then you are estimating in the sprint from 13th to 24th January.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

It is good practice to have at least two such 1-hour events or one 2-hour event in a two-week sprint. This allows you to keep the top of the backlog always in a worked and evaluated state.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

Usually such a meeting is held by the Product Owner, at least he initiates it.

Training:

1. Before each PBR, the Product Owner has a plan for what we want to evaluate in that hour or two.

At the meeting:

1. We remind the team of the scale of story points, which we agreed on initially. It is usually stored on a page in Confluence.
2. We check each of the tasks for compliance with the Defenition of Ready. It’s convenient to make a template in the task tracker that you go through every time.
3. (First option) We decompose each of the tasks into subtasks and evaluate each one in Story Points, then add it up and get the final score for each of the tasks.
4. (Second option) Evaluate each story as a whole without decomposition
5. At one of the PBRs, we discuss the future goal of the sprint and evaluate it, as in paragraph 3