Product Backlog Refinement

Ongoing Product Backlog Refinement (PBR) is needed within each Sprint to refine items to be ready for future Sprints. Key activities of PBR are (1) splitting big items, (2) detailing items until ready, and (3) estimating. In the spirit of empirical process control, Scrum does not say how to do PBR, though suggests that the Team spend no more than 10% of their Sprint capacity on it. It usually happens “mid-Sprint.”

Note! Refinement of items is not done separately by the Product Owner or a business analysis group—doing that would increase the lean wastes of hand-off and information scatter. Rather, the Team does this work—and not a subset of the Team, but the whole Team, as Scrum rules prohibit sub-groups dedicated to particular domains such as analysis or testing.

Product Backlog Refinement Overview

Product Backlog Refinement is often done in:

  • Overall Product Backlog Refinement (shared amongst all teams)
  • Team-level Product Backlog Refinement
  • Multi-team Product Backlog Refinement

Overall Product Backlog Refinement

The LeSS rule raises the questions: How to decide which teams are likely to implement which items? And there are the scaling issues just examined: shared understanding, coordination, common work, aligned estimates, and balancing specialization and agility.

An overall PBR session addresses all of these. In brief, hold an overall PBR workshop with representatives before the individual team PBR sessions, to explore which teams might work on which items, and to increase learning and alignment. Attendees include the Product Owner, subject-matter experts, and either all members of all teams or a couple of representatives from each team. Representatives are usually preferred, to keep the meeting smaller and to not have everyone in yet another meeting, though the cost is information handoff and scatter.

Do the following:

  • split big items
  • do very lightweight item analysis for basic understanding
  • estimate items
  • identify strongly-related items that suggest shared work, common work, or coordination

Team-level Product Backlog Refinement

When an item will clearly be done by one team and it won’t be too strongly related to other items, then the Product Backlog Refinement is the same as in a one-team Scrum. The team does the refinement themselves, ideally together with users/customer/stakeholders and they inform the Product Owner related to changes (splitting, new estimates) in the Product Backlog.

Multi-team Product Backlog Refinement

Multiteam PBR is when more than one team are (literally) in the same room at the same time doing PBR. Attendees include subject-matter experts, and either all members of the participating teams or a couple of representatives from each.

How is it different from overall PBR? Overall PBR includes participation from all teams, but multiteam PBR may involve as few as two teams. It is also more likely to include all members rather than representatives.

Do multiteam PBR to increase shared understanding and exploit coordination opportunities when a group of teams are working on a common family of items or strong-related items.

Multiteam PBR may be a complement or replacement to team PBR.