The Backlog Refinement

Backlog Refinement is a regular session in which the Product Owner and product ownership circle (architect, UX, stakeholders and often even all team members) discuss the further direction of the product, propose features and break them down in a little bit more detail.

We want to have our backlog in a good shape populated with relevant items and keeping the current understanding of the product/system and its objectives. The backlog should be dynamic, not all details are necessary (see As Late As Possible principle).

The session is lead by the product owner, ScrumMaster, however, prepare it and moderate it properly.

The goals of the backlog refinement

  • To ensure the vision is still valid.
  • To shape the product/system.
  • To identify epics & themes.
  • To break down epics into features and maybe user stories.
  • To prioritize high-level features.

How often?

This activity is either repeated once per quarter (typically), or it is a continuous effort. Top priority requirements have to be described precisely (see Definition of Ready) as they will be implemented soon. This is however not so necessary for the backlog grooming session itself, it might be done later by the product owner itself.

The backlog is typically designed in form of User Story Map.

scrumdesk user stories story mapping epic feature backlog item owner moscow product

If the product is more complex, the Program board is helpful to track the complexity of dependencies. It is used more in the release planning sessions, however, might be useful in the refinement session as well.

Release-Planning-PSI-Program-Plan-1

The Scrum Guide even suggests having regular Backlog Refinement sessions in every sprint and to invest up to 10% of the capacity of team into it.

At the end of the refinement session, it is great to update the product roadmap as well, if necessary.

scrumdesk roadmap epic feature milestone planning agile scrum product backlog owner planning sprint release

Agenda

  1. The vision of the product. Business stakeholders and the Product Owner should review the vision and currently developed product. Is it still what we want to achieve? Do we head towards the same vision as in the past? Or do we need to adapt the vision?
  2. The outlook for the next time period (quarter, half a year?). Strategic business themes are described in detailed goals we want to target in the upcoming months.
  3. Customers, their jobs, pains and gains we want to target.
  4. Identification of epics, features, user stories we decided to remove from the backlog.
  5. Identification of new epics and their business value evaluation. Identification of important enablers needed to achieve specified goals.
  6. Break down epics into features or even user stories. First wireframes and architectural designs are made as well.
  7. Identification of dependencies with other products, systems or teams.
  8. Prioritization of epics and features. Identification of risks. First complexity estimation if needed. Weighest Short Job First (WSJF) method might be helpful.
  9. Agile roadmap with epics and features.

Should team members participate?

Yes, why not? Anyway, experienced agile teams used to participate in backlog grooming as well. For the great agile team, this is a ceremony where they shape the product they build. From the perspective of an employer, this is the place where the connection between the developer and product is established. They define THEIR product. It is about collective ownership.

Also known as

Originally, the backlog grooming term was used in agile however due to the negative connotation of the word grooming Backlog Refinement is used more widely now.