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) clarifying items until ready for implementation without further “what” questions, and (3) estimating size, “value”, risks, and so forth. In short form: split, clarify, estimate. 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! Clarification 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 entire Team does this clarification — 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

In LeSS PBR is an expected formal event (workshop meeting) rather than just an unspecified “activity”, and is done in:

• Multi-team PBR
• Overall PBR
• Single-team PBR

Multi-team PBR

Multi-team PBR is arguably the most important event 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. (Multisite variations are discussed in the LeSS books.) 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 (or in the case of LeSS Huge, all teams within one Requirement Area), and therefore all team members. “All teams” is the recommended default 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 clarification until items are “ready” for implementation without further “what” questions
• estimate items in terms of size, “value”, risks, and other relevant factors
• identify strongly-related items that suggest shared work, common work, or coordination

During a multi-team PBR event try the following to increase cross-team learning, cross-team conversations and social connections, and to see more opportunities for cross-team coordination: mixed-up group refinement

1. mix the people in N Teams into N groups, where people in each group are from each Team
2. in parallel each mixed-up group clarifies different items for a period of time
3. rotate the groups across the items so that over time all groups have refined all (or most) items

Overall PBR

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

The normal motivation for an overall PBR event 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.

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 the wastes of information handoff and scatter.

A key point: Overall PBR is short-ish. Activities are similar to multi-team PBR, but instead of detailed clarification (which takes lots of time), do quick and lightweight item clarification for basic understanding.

A second and should-be-rare case for overall PBR — related to the short-ish point — is when the Product Owner unfortunately can’t attend (the long and in-depth) multi-team PBR event because of a hard constraint (“I’m going to Hawaii for a vacation”). This should be rare; the Product Owner should normally be engaged in multi-team PBR. But complications happen and in that case at least an overall PBR event provides some interaction with the Product Owner across all relevant upcoming items.

Single-Team PBR

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.