Multi-Team Backlog Refinement

What is Product Backlog Refinement?

Product Backlog Refinement (PBR) is an activity that Scrum Teams regularly do to clarify potential upcoming Product Backlog Items (PBI). In single team Scrum, typically the Scrum Team gets together for one or more workshops during a Sprint to create and maintain a Refined Product Backlog. 

Below some example activities you can consider:

• Understanding what the right problem to solve is: The Product Owner tells a coherent set of stories with a goal and links them back to the business objective. The team discusses why they are setting thos goals and ensures they are solving the right problem. Some teams use story-maps, impact-maps, Speedboat, Me and My Shadow, or the 5 Whys. 
• Splitting big items for discussion and learning
• Estimating items for learning and alignment
• Understanding Customer needs: The team this time asks, “Why does the user want this?” and, "Are we solving the problem correctly?" Some teams use a storyboard (before/after) and pain gain maps.
• Clarify Items: Some teams use Specification By Example and create acceptance tests for the user stories; others use story narratives with Gherkin specifications, flow tables and/or decisions tables.
• Define Exploratory Test Charters: Identify risks to target and which features need manual testing. Some teams use an exploratory test charter for each and use exploratory testing tours to test as a team.
• Create initial designs: Modelling at a whiteboard, design sketches,…

Teams that work together on a single product can benefit from doing multi-team refinement. But how can you do refinement with multiple teams at the same time? And why should you?

Why Multi-Team Refinement?

Multi-team PBR is when all members of all teams refine PBIs together without yet deciding which team will implement which item.

Below you can find some benefits that multi-team refinement can give you: 

• Adaptability at the product level. Why? Because all teams understand all PBIs on the Product Backlog, instead of each team understanding only their PBIs, a subset of the Product Backlog. If all teams understand all PBIs then the PO can put any PBIs she seems most valuable at the top without being constraint to the PBIs a particular team understands.
• Improved self-coordination so the teams maintain a broad understanding of the whole product and the upcoming PBIs, and therefore, are more likely to know of "dependencies" between PBIs.
• A transparent measure of progress at the product level for all teams to participate in estimating all PBIs so there is one common velocity at the product level, instead of a distinct velocity per team that needs to be combined into a total.

How to Do Multi-Team Refinement?

The activities for single team refinement can also be used with multi-team refinement; the biggest change is in the facilitation of large groups.

I like to create new groups from the teams that participate in a refinement session instead of using the regular teams. So, let's say that there are four teams A, B, C, and D. Then at refinement, I ask the teams to form four new groups, each group consisting of a person from team A, B, C and D. Why? With groups consisting of members from each team, all PBIs are refined by at least one person of every team. This creates a shared ownership and broad understanding of the PBIs.

Multi-Team Refinement Formats

When I work with teams, I show the teams 4 ways of doing multi-team refinement so that the teams can then choose the way they like most to continue with and improve.

I work with the following 4 formats:

1. Full Roulette

Each group picks a PBI for refinement and start refining at their station. After a timebox — I like 15 min timeboxes — all groups move to the next station and continue refining where the other group left off; this is continued until the PBIs are refined or the workshop timebox expires. The groups can use whatever technique they like for refinement. 

The full roulette results in good refinements because the groups feel pressure to leave their work clear and understandable as possible for the next group.

2. Partial Roulette

Just like Full Roulette, but instead of the whole group moving to another station, one person stays at the station. This person then teaches the new group what was discussed before they continue with refinement.

I use this approach in the beginning because is that it is easy to start with. After the teams have experienced this Partial Roulette, I encourage them to try Full Roulette.

3. Diverge and Merge

In this approach, the groups do a diverge-merge action after each timebox. One person stays at each station and becomes the teacher. Then all groups send a person to each of the other stations. So, let's say you gave groups A, B, C, and D. Then 1 person from group A stays at the station to teach back and 1 other person visits group B, another group C and another group D. After the teach back, the persons return to their original group and share their learnings. Any puzzles, questions are then discussed as a group.

I have worked with this technique with up to 35 people or so.

4. Teach Back

Each group picks a PBI and refines it. After the timebox is over, each group teaches their work so far back to the other teams and have a Q&A discussion. 

This technique doesn't work as well with a large number of teams, because the teach backs easily take too for long for big groups, and it's harder to have a focused discussion with lots of people.

Role of the Product Owner and Customers

During the refinement sessions, the Product Owner (PO) and customers play an important role. The Product Owner has to be prepared and understand what is needed from a business perspective. The PO will discuss overall topics like the Story Map and participate in each group when requested. 

You also would like the end-customers or people closest to the end-customers like sales to participate in detailed refinement sessions.

The approach I like the most and have seen be most effective is the Full Roulette. If you decide to try any of the above approaches, I would enjoy hearing from you about how it worked out.