In this little blog I share some tips for multi-team Product 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 is the right problem to solve: The Product Owner tells a coherent set of stories with a goal and links them back to the business objective. The team discusses “why we are doing this?”, “how do we know we 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 discusses “Why does the user want this?”, “Are we solving the problem right?”. 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; use story narratives with Gherkin specifications, flow tables and/or decisions tables.
Define Exploratory Test Charters: Identify risks to target; Identify which features need manual testing. Some teams use exploratory test charter for each and use exploratory testing tours to test as a team.
Create initial designs: Modelling at whiteboard, design sketches,…
( see our paper in Testing Experience magazine for some more examples )
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: (there are many more benefits, but that would make this blog too long)
- 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: Why? because 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.
- Transparant measure of progress at the product level. Why? because all teams participate in estimating all PBIs and therefore 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 about 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:
0. 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 the 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.
1. Partial Roulette
Just like Full Roulette, but instead of the whole group moving to another stations, 1 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.
2. 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.
3. 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 works not so good with a large number of teams, because the teach backs easily take too for long for big groups, and its 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 the business perspective. The PO will discuss overall topics at for example a Storymap and also participate in each group when requested.
You also would like the end-customers or people closest to the end-customers like sales, helpdesk etc 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 how it worked out.
Cesario Ramos works on large-scale transformation all over the world in banking, insurance, and high-tech industries. He started back in 1999 with eXtreme Programming and started his first Scrum Team back in 2002. Ever since he has been working with organizations adopting Scrum in roles from programmer, architect to CTO and Product Manager. In 2010 he founded AgiliX, a consulting company, that provides consulting and training worldwide.
Cesario is the co-author of the books ‘Creating Agile Organizations‘, ‘A Scrum Book’, and author of the the book ‘EMERGENT’. He is also a Certified LeSS Trainer, Professional Scrum Trainer and Professional Coach.
He is a frequently invited speaker at conferences around the world. He spends his free time on Rock Drumming, wine tasting and mathematics.