Before and during the Sprint, effort needs to be put into coordination to ensure the Scrum Teams deliver a working integrated product. This situation can be improved with Multi-team Product Backlog Refinement sessions. This practice increases flexibility and speed in product development. Use this article as a cookbook to get familiar with this practice yourself.
What is Multi-Team Product Backlog Refinement (mt-PBR)?
The Scrum guide specifically mentions refinement, but does not elaborate on how to do it:
“The Scrum Team decides how and when refinement is done.“ (SG)
Multi-team product backlog refinement (mt-PBR) is a practice proposed in the scaling framework LeSS. The goal of this practice is to maximize information sharing and collaboration during product backlog refinement. The main idea is to bring the whole development group together in one refinement session instead of teams conducting separate refinements. This allows everybody to contribute and it helps to create a shared understanding of the work. Even if your company does not use LeSS, you most probably will appreciate this refinement practice.
Why choose mt-PBR?
It makes sense to try out mt-PBR when:
- You want to prevent integration issues by having teams to collaborate. This will prevent those issues from occurring.
- You have multiple teams working on the same product (increment) and you want to keep whole product focus.
- You want to reduce the coordination effort that is needed to manage dependencies between the teams.
- You think it is important that team members learn from each other.
- You want to maximize collaboration between teams.
Preconditions
- In order to get the anticipated benefits of MT-PBR, you will need a single product backlog and one Product Owner. Please refer to one of my earlier articles for more background on this point of view. It’s ok if you have many PO’s running around the teams, as long as there is one single person who takes responsibility for the whole product. This person will be your “partner in crime” for conducting the MT-PBR (I am assuming you are a Scrum Master).
- 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 am not sure how this approach will work with larger groups.
- At every customer where I introduced this practice, the teams were cross-functional. Meaning that every team can design, test and build software. I suspect this practice will not work very well with single function teams (analysis, test, development in separate teams).
- Lastly, to make reliable estimates, a good Definition of Done (DoD) is needed. If you are not sure how valuable the DoD is for all your scrum events, please refer to this article.
Preparations
Before we can start the mt-PBR sessions, the Product Owner (PO) and Scrum Master (SM) need to prepare one or two things.
The Product owner:
- Needs to prepare the top of the backlog by identifying a series of Product Backlog Items (PBI’s) that need to be refined. Let’s say 10/15 larger items. About 10 of those items could be selected for a single two-week sprint for 8 teams. This gives you an idea about the size of the PBI’s.
- Needs to describe the PBI’s as goals, not as outputs.
- Needs to provide customer-centric acceptance criteria to the PBI’s.
- Needs to prepare the product vision and short-term goals (let’s say for the current quarter). Creating impact maps is a very suitable technique for this.
- Sends an invitation to the whole group & relevant stakeholders.
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.
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 straight after each other.
Part-1: Overall Refinement
This is a session that prepares for the detailed refinement session (part-2). The attendees are team delegates (development team members) and Subject Matter Experts (SME’s). The session takes 30 minutes to an hour.
The output of the session is a set of PBI’s for one Sprint that have been discussed briefly, with a t-shirt sized estimate, acceptance criteria and known dependencies.
Session details
The PO briefly iterates the product vision and mission (the quarterly goals). 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 this prioritization of the Product Backlog.
The team delegates form heterogeneous groups of 3/5 people to discuss one PBI each. They estimate PBI’s and split them if they seem to be bigger than one sprint. They also identify dependencies, which are indicators for team collaboration (during refinement and during the Sprint). Note that probably not all of the selected PBI’s require multiple teams to work on.
The team delegates will guide the rest of the group during part-2, the upcoming detailed(multi-team) refinement. They will share their insights with the rest of the group. To increase the value of the detailed refinement, I advise to close the overall refinement by the attendees doing a teach-back of what they learned/what is decided regarding the selected PBI’s.
Part-2: Detailed multi-team refinement
Immediately after the Overall Refinement, the detailed multi-team refinement starts. All development team members need to attend. Note that this is not an optional meeting. Anybody that holds relevant knowledge for the PBI’s (such as SME’s, architects, domain model experts, etc) should attend too. This part of the session usually takes two hours.
At the start of the mt-PBR (part-2), the group gets informed about the PBI’s by a Subject Matter Expert.
Session details
The session starts centrally with the PO briefly iterating his product vision and mission and the (quarterly) goals. The SME’s or Team delegates who were present at the Overall Refinement introduce the selected PBI’s. They also share which teams are likely to collaborate. There is no need for much technology, the items are on large sticky notes and visible on the wall.
The proposed backlog items
When all PBI’s were introduced there is usually a short question round. The PO then picks up one PBI at a time and asks the people who will refine that item. Guided by the team delegates, the people now form heterogeneous groups to refine the PBI’s in detail. We deliberately break up the existing teams to stimulate knowledge transfer. Sometimes multiple groups refine the same PBI. To support working with remote attendees, we created “numbered Stations” with a room in hangouts. A group that picks up an item calls the station number, so everybody knows which hangout they will be working in.
People from different teams refine a PBI in detail.
If an item has no dependencies, any group can refine the item. This might be people from a single Scrum Team. The PO, SM and SME’s walk around and support the groups when needed. They contribute to good refinement quality by asking powerful questions.
Each group clarifies the acceptance criteria by creating initial designs, examples or scenario’s that describe how the PBI can be tested. Any question and input that is prerequisite to take the PBI into the Sprint needs to be addressed.
Iterations
When the groups have worked on their item for about 15 to 20 minutes, we start iterating by rotating the groups to continue refining the PBI’s with different people. We iterate and rotate because our goal is to use the full potential of the whole group. Everybody understanding most of all PBI’s will create flexibility, it will make decisions easier and it creates speed because of the mitigation of integration issues.
There are various iteration techniques:
Partial roulette: each group works on an item. When the time-box expires, one person (SME) stays behind at the station, the other people move to the next station to continue refinement.
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: each group works on an item. When the time-box expires, one person (SME) stays behind at the station, all other people split up so all other station can be visited. They get taught about the other PBI for 5 minutes and then return to their station to discuss learnings. Each group 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 may be time consuming with large groups, which is not desirable.
We iterate the refinement rounds two to three times, as many as needed and fit into the time-box. We finish by recording the results. The session is concluded centrally by the PO going over the PBI’s, asking for open ends, which teams are involved doing what, etc.
During, but mostly after the session, people make notes and create items in their Scrum tool (Jira or TFS or the likes) as needed.
The complete schedule in a nutshell
9:30–10:30 prepare and setup 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
- intro 15 min
- multi team PBR 60 min (3x partial caroussel)
12:15 -12:30 closing
done!
Enjoy your multi-team Product Backlog Refinements.
Roland