Multi-team PBR is one of the Elevating Structures that help to uplift your ecosystem up the levels of the Org Topologies™ mapping:
This article focuses on refining the Product Backlog with multiple teams at the same time: multi-team Product Backlog Refinement (aka mt-PBR). The goal of mt-PBR is to maximize information sharing and collaboration during Product Backlog Refinement. We bring all development teams together in one refinement session instead of having teams conducting separate refinements.
Refinement in Scrum
The Scrum guide mentions refinement, but does not elaborate much on how to do it:
“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.” (Scrum Guide)
When we develop a product with more than one team, the Scrum guide suggests to have one single Product Owner and One single Product Backlog:
If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner. (Scrum Guide)
This suggests a move towards the higher archetypes (B and C levels) as per Org Topologies™. Maybe that is too scary or simply not what you want. However, even without transforming your organisation, you might want to explore and benefit from Scrum events such as Product Backlog Refinement with a team of teams.
Why would you want to do a mt-PBR?
It makes sense to try out mt-PBR when:
You want to create a shared understanding of the work. In other words, you want the teams to focus on the whole product or problem at the same time rather than splitting the work into smaller items per team upfront.
You want to reduce the coordination effort that is needed to reduce dependencies between the teams when they work asynchronously from each other in isolation.
You want to minimize integration issues that will occur if the teams do not integrate during the Sprint.
You have the opportunity of dealing with a challenge that affects multiple teams. This could be a shared problem or a Product that is been developed by multiple teams and you want the teams to collaborate on that challenge to increase the chances of success.
You think it is important that team members learn from each other and you want to give everybody the opportunity to contribute to creating the best possible value.
Preconditions
In order to get the anticipated benefits of mt-PBR, you will need a single product backlog and one Product Owner. It’s okay if you have many POs running around the teams, as long as there is one single person who takes responsibility for the whole product (or the cross-team problem you are addressing).
There is a restriction on the number of people involved. I have used this practice with up to 70 development team members, say about eight teams. I know there are colleagues who have run successful mt_PBRs with up to 150 attendees.
At every customer where I introduced this practice, the teams were cross-functional (archetypes A2 or A3). Meaning that every team can design, test, and build software. I suspect this practice will not work very well with single-function teams of Y2 level (analysis, test, development in separate teams).
You need a cross-team Definition of Done (DoD) so all teams have a shared understanding of what needs to be done to be Done.
Preparations
Before we can start the mt-PBR sessions, the Product Owner (PO) and Scrum Master (SM) need to prepare the session.
The Product owner:
Needs to shape the top of the backlog by identifying the Product Backlog Items (PBIs) that need to be refined. Let’s say 10 or 15 (larger) items, enough work that will take one or more Sprints to complete with the whole group.
Needs to describe the PBIs as goals, not as outputs.
Needs to provide customer-centric acceptance criteria for each PBI.
Needs to prepare the product vision and shorter-term Product goal (let’s say for the current quarter or less). Consider impact maps as practice.
Sends an invitation to the whole group, relevant stakeholders, and Subject Matter Experts (SMEs).
The Scrum Master:
Needs to book a space that is large enough for the group to work in and with sufficient wall space to work on.
Needs to ensure there are flip-overs, brown papers, stickies, markers, etc.
Needs to ensure there are “stations” or desks where groups of people can work.
Needs to arrange a beamer and possibly a loudspeaker system.
If there is no common understanding of “Done” across the teams, the Scrum Master needs to establish a minimal DOD that applies to all teams. While refining, this will create transparency on the work that needs to be done for each item.
Often the work is estimated while refining. The Scrum Master should ensure the unit of estimation (possibly story points or t-shirt sizing) is calibrated across teams. This will prevent wasteful discussions between members of different teams when estimating.
mt-PBR session process
The mt-PBR consists of two parts:
part 1: Overall Refinement part 2: Detailed (multi-team) Refinement
The two parts are planned directly after each other.
Part 1: Overall Refinement
This is a session that prepares for the detailed refinement session (part 2). If you have never worked with large groups in sessions, you will be happy to learn that the overall refinement session is done with a small group of delegates from the teams. It is a meeting that has a size you will be familiar with: no more than around 10 people. The attendees are team delegates (development team members) Subject Matter Experts (SMEs) and possibly Product Managers. The session takes 30 minutes to an hour. The input of the session is the top of the Backlog as prepared by the PO. The output of the session is a set of PBIs for one Sprint that has been discussed briefly, with a rough (t-shirt-sized) estimate, acceptance criteria, and known dependencies.
Session details
The PO briefly iterates the product vision and mission (the Product goal). This provides context, “the Why” for the work that we are about to pick up. This helps everybody to understand why the PO has chosen to prioritize the Product Backlog the way he or she did. The team delegates form heterogeneous groups of 3 to 5 people to discuss one PBI each. This is important. They do not work on the problem with their teammates. They estimate PBIs and split them if they seem to be bigger than one sprint. They also identify dependencies, which are indicators for possible team collaboration during the Sprint. Note that probably not all of the selected PBIs require multiple teams to work on.
A great benefit of the Overall Refinement is that the team delegates will later be able to guide the rest of the group during the upcoming Detailed Refinement. They will share their insights with the rest of the group. To increase the value of the detailed refinement, we close the overall refinement by the attendees doing a teach-back to each other of what they learned and what is decided regarding the selected PBIs.
Part 2: Detailed multi-team Refinement
Immediately after the Overall Refinement, the detailed multi-team refinement starts. This session requires strong facilitation. Ask your Scrum Master to help out! All development team members must attend. This is not an optional meeting. Anybody who holds relevant knowledge of the PBIs (such as SMEs, architects, domain model experts, etc.) should attend too. This session can take two to four hours. You will need to experiment to learn what works best in your context.
The group gets informed about the PBIs by a Subject Matter Expert.
Session details
The session starts centrally with the PO briefly (re)sharing the product vision, mission and the current Product goal. The SMEs or Team delegates who were present at the Overall Refinement introduced the selected PBIs. They also share which teams are likely to collaborate during the Sprint. There is no need for much technology, the items are on large sticky notes and visible on the wall.
the Product Backlog
When all PBI’s are introduced there is usually a short Q&A. When that’s done, the PO picks up one PBI at a time and asks the people who will refine that item. Guided by the team delegates, the people will self-organize in heterogeneous groups to further refine the PBI’s. Note that we deliberately break up the existing teams to stimulate learning and knowledge sharing. Sometimes multiple groups refine the same PBI.
You can make this a hybrid meeting by creating “numbered Stations” with a room in zoom or teams. A group that picks up an item calls the station number, so the remote attendees know which (virtual) room they will be working in.
Members of different teams collaborate in refining.
The PO, PMs, SM, and SMEs walk around and support the groups when needed. They contribute to the refinement by asking powerful questions.
Each group clarifies the acceptance criteria by creating initial designs, examples, or scenarios that describe how the PBI can be tested. Any question and input that is a prerequisite to taking the PBI into the Sprint needs to be addressed. People verify existing code if needed. The groups use the DOD here to verify if everything we need to do to meet our quality standards is addressed.
Iterations
When the groups have worked on their item for about 15 to 20 minutes, we rotate the groups across the items to continue refining the PBIs with different people. We iterate and rotate because our goal is to use the full potential of the whole group. By ensuring everybody knows most of all PBIs to some extent we create flexibility: it will make decisions easier, multiple teams can collaborate on an item as all teams will have (some) knowledge about the item, it mitigates integration issues and increases self-organization.
There are a number of iteration techniques:
Partial roulette: each group works on an item. When the time box expires, one person stays behind at the station, the other people move to the next station to contribute to the refinement of another item.
Full roulette: each group works on an item. When the time-box expires, all people move to the next station to continue refinement.
Diverge and merge: Our favorite! Each group works on an item. When the time-box expires, one person (SME) stays behind at the station, all other people split and go to a random other station. They get taught about the other PBI for 5 minutes, give feedback and suggestions and then return to their station to discuss learnings. Each group then continues refining their initial PBI.
Teach-back: each group works on an item. When the time-box expires, all people gather around one station where the SME explains the findings. All stations are visited sequentially. This is time-consuming with large groups.
We iterate the refinement rounds as many times as needed. Mostly two to three times is enough. Also, we stop when the time box expires. Before we end the meeting we record the results by taking pictures or otherwise. The session is concluded centrally by the PO going over the PBIs, asking for open ends, which teams are involved in doing what, etc.
During, but mostly after the session, people create items in their work management tool (Jira, TFS, or the likes) as needed.
The complete schedule in a nutshell
9:30–10:30 Prepare and set up the room
10:30–11:30 overall PBR
– intro 20 min.
– refine 20 min
– closing 20 min
10:30 -10:45 break
10:45–12:30 detailed PBR (longer if needed)
– intro 15 min
– Multi-team PBR 60 min (3x 20 min diverge/merge
12:15 -12:30 closing – done (time for lunch)!
Alexey Krivitsky and Roland Flemm
