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 the Scrum Guide observes that the Team usually spends 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:

  • Multi-team Product Backlog Refinement
  • Overall Product Backlog Refinement
  • Single-team Product Backlog Refinement

Multi-team Product Backlog Refinement

Multi-team PBR is arguably the most important meeting in LeSS to drive effective Sprints with well-aligned, coordinated, and adaptive teams. Multi-team PBR is when multiple teams are (literally) in the same room at the same time doing PBR. Attendees include all members of all participating teams, and may also include subject-matter experts, users, customers, and the Product Owner. Big workshops are better with a skilled facilitator, and this is a great adjunct role for a Scrum Master.

Do multi-team PBR to increase shared understanding, exploit coordination opportunities, align estimates, and increase adaptiveness across teams.

It usually includes all teams in the product group — and therefore all team members — and this is the recommended default when possible, as it supports total group improvement. But multi-team PBR may involve as few as two teams.

Do the following:

  • split big items
  • do detailed item refinement until items are “ready”
  • estimate items
  • identify strongly-related items that suggest shared work, common work, or coordination

And try “rotation refinement” in which the “eight” teams first mix into eight groups, and then the eight groups in parallel refine different (or even the same) items for a period of time, and then rotate the groups to different items.

Overall Product Backlog Refinement

Prefer multi-team PBR with all teams, with the Product Owner. And in that case, don’t bother with overall PBR. So when might it be useful?

One case is when the group may want to divide related items into (for example) two major subsets and have (for example) four teams work on one subset, and another four teams work on another subset. In that case, hold an overall PBR workshop with representatives from all teams, and the Product Owner, to (1) support brief and lightweight total-group learning and coordination for all upcoming items, and (2) to identify major subsets of strongly-related items and related sub-groups of teams that will later focus on them, in different multi-team PBR sessions.

For example, in a product group with eight teams, in a common overall PBR session it is decided that three teams focus together on related items in their own three-team multi-team PBR, and another five teams likewise in their own five-team multi-team PBR.

A second case for overall PBR is when the Product Owner can’t attend (a long and in-depth) multi-team PBR session, but wants to keep in touch and provide guidance for the teams in their PBR work. Since overall PBR is “short-ish” and is not a deep dive into item details, it provides a chance for the Product Owner to be involved in a shorter meeting.

Attendees include the Product Owner 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.

Activities are similar to multi-team PBR, but instead of detailed clarification (which takes time), do quick and lightweight item clarification for basic understanding.

Single-Team Product Backlog Refinement

Single-team PBR should be rare in LeSS, as it inhibits group learning, weakens coordination and alignment, and reduces adaptiveness. One situation it’s relevant is when the LeSS Guide Leading Team is being used, in the early phase of their work. A Leading Team is used when there is a gigantic item to work on (“add support for the new federal tax law revisions”), that will eventually involve many teams, but the group is still at the fuzzy front end of understanding the enormous item. In this case, one Leading Team volunteers to first investigate and incrementally create code for the giant item, all by themselves, for several Sprints. Key point: during this phase they may do single-team PBR. After the Leading Team has cleared the fog on the gigantic item, more teams join the effort and the Leading Team shifts to doing multi-team PBR with the other teams.