Product Backlog Refinement (PBR) is an ongoing process in Scrum. But in a scaled Scrum, complexity vastly increases, and Refinement becomes mandatory. In this article, I will explain how you can use Refinement to your advantage and enhance organizational agility.
Talking to a Newbie Scrum Master
Some time ago, I was talking to a newbie Scrum Master who was going to launch a product group along with me. We were in a week before the first Sprint and were about to start the kick-off activities. The Product Group consisted of several Scrum Teams working on the same product.
I asked the Scrum Master: “I wonder what the first event or activity you would like to focus on and make it perfect. Is it Sprint Planning, Daily Scrum, or...?” She thought for a while and responded that it was the Sprint Planning. The answer makes sense because Sprint Planning is the first event in any Sprint. Well, is the answer so obvious?
Dual Nature of Scrum
Scrum has a dual nature and made of two entities. The first one is the Product Organization, which contains people, teams, roles, and relationships. The second one is the Value Stream, which is the flow of speculations (requirements) to the “Done” increment. It’s vital to pay thorough attention to both entities to build a proper implementation of Scrum. Both entities visualized in separate pattern languages. If you haven’t dived into Scrum Patterns, yet these articles might help you to grasp the basics:
Focus on Refinement
Refinement reduces the variability of Product Backlog Items before they enter the Sprint. The Law of Variability Placement [HS08] reveals that the worst place for variability (in terms of negative cycle-time impact) is at the front end of a multi-stage system with queues. Sprint is a multi-stage system. When Product Backlog Items become “ready”, a Development Team has fewer “surprises” during a Sprint, and the chances to reach the Sprint Goal increase.
My suggestion is that you should focus on the Product Backlog Refinement (PBR) at the very start. Sufficient refinement is indispensable in a scaled Scrum. The first refinement should happen before the first Sprint. It shapes the Product Backlog and prepares it for inspection during the Sprint Planning.
Below is a sequence example that I often use in my coaching practice to launch the requirements flow in a product group: Vision -> Product Roadmap -> Product Backlog -> (Refined Product Backlog | Information Radiator) -> Small Items -> (Definition of Ready | Estimation Points).
What is not obvious for most Scrum practitioners, though, is that Refinement is the
tool for enhancing the agility of the product group. Let’s investigate that statement in detail.
Single-Team and Multi-Team Refinements
In scaled Scrum teams are working on the same product:
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product (Scrum Guide).
There are two major Refinement formats in a scaled environment: Single-Team and Multi-Team. Single-Team Refinement is an event for one of a few Development Teams. Multi-Team Refinement involves two or more Development Teams that are collaborating on the details of the Product Backlog directly with the stakeholders and end-users. Multi-Team Refinement provides several benefits for the product group:
- Supports coordination in Sprint
- Increases tactical and strategic agility.
If you are interested in the concrete tips and practices on how to facilitate Multi-Team event, please read:
Coordination Based on Self-Organization
When multiple teams are collaborating on the Product Backlog Items, it leads to an increased shared understanding of the Product Backlog and the whole product. Two or more teams know the details of a set of Product Backlog Items (PBIs). Thus, each team knows what other ones are doing “around the corner,” and they can easily coordinate work and any kind of dependencies themselves. No need for dedicated coordinators and boring coordination meetings. Multi-Team Refinement creates necessary conditions for emerging coordination, which based on self-organization. Look at Figure 1:
Temporary Stress
What I noticed in my coaching practice is that teams sometimes resist a Multi-Team Refinement. There are many reasons for that, but the major one is the knowledge gap. When teams have been working in product silos for a long time, they have a culture of narrow specialists. Developers feel uncomfortable stepping out of their habitual zone. Besides, collaborating directly with the end-users and customers might feel stressful as well. So, use Multi-Team Refinement with caution. Maybe it’s not a good idea to invite 6-8 teams from the very beginning. You may expand product focus gradually. Look at Figure 2:
Tactical and Strategic Agility
Multi-Team Refinement also impacts tactical and strategic agility. By tactical agility, I mean the ability to for the teams to select features they will be working on as late as possible. By strategic agility, I mean the level to which a product group is capable of supporting its Product Owner in significant product development change. That might happen due to disruptive technology changes or other dramatic events in the market. Look at Figure 3:
Select Your Combination of Single-Team and Multi-Team Refinement
I have successfully facilitated Multi-Team Refinements for up to 6 teams in one room. Those events lasted for 2-3 hours and resulted in a set of 4-8 “ready,” features that any team could select for the upcoming Sprint. Indeed, Multi-Team Refinement provides substantial benefits, but from my experience, you need to come up with your combination of Single-Team and Multi-Team Refinements. Think of it as a spectrum where you choose a position between Humble Agility (using only Single-Team Refinements) to Radical Agility (using only Multi-Team Refinements only). Look at Figure 4:
I want to provide a few examples to illustrate the idea.
MTS Kassa Case Study
Let me share an excerpt from an MTS Case Study. The product group contained seven feature teams working on the same product. Team representatives collaboratively co-created a new process for Refinement. This is the combination of Refinements they came to at first.
The product group worked in two-week Sprints. The refinement process started with preliminary overall Refinement with team representatives. That was a short meeting to understand what Product Backlog Items (PBI) are to be discussed and refined in-depth further. Ukrainian team usually conducted its Single-Team Refinement and a narrow product focus reduced product group agility. Justification for this decision was a team remoteness. The other 6 teams split into two groups of 3 and had parallel Multi-Team Refinements. The reason for the latter was rather prosaic. The head office didn’t have a big enough room to accommodate all teams at once.
OK Alpha Case Study
The product group contained five cross-functional teams working on the same product. Unfortunately, they were not structured optimally from the start and had a few narrow specialists that traveled between teams. Teams complained about duplicating functionality, lack of product focus, out of sync development. The product group morale was steadily going down during the last several Sprints. It turned out they worked strictly in Single-Team Refinement mode.
For me, it was clear - they worked in product silos that created local identities and hampered collaboration. Silos reduced the ability to adapt to market changes. The solution was to conduct useful and valuable Multi-Team Refinements with all teams at once. Below you can see the photo from the first Multi-Team Refinement that we held:
I remember the outcome of the first Multi-Team Refinement. It was fascinating: people energized and happy with it. That’s not surprising as a Multiteam Refinement involves all people in one room and makes them productive. No asynchronous dependencies, the issues are being dealt with all at once. The product group used Multi-Team Refinement successfully afterward.
Pick Out Your Combination of Refinements
In this article, we investigated how to enhance agility (both tactical and strategic) in a scaled Scrum with Refinement. All you need now is picking out your combination of Single-Team and Multi-Team events for the benefit of the product group. I hope this article was useful to you.
Main Ideas
- Scrum has a dual nature and made of two entities: Product Organization and Value Stream
- Refinement reduces the variability of Product Backlog Items before they enter the Sprint
- There are two major Refinement formats in a scaled Scrum: Single-Team and Multi-Team
- Multi-Team Refinement provides several benefits for the product group: supports coordination, increases tactical and strategic agility
- Multi-Team Refinement causes temporary team stress because of the knowledge gap
- Refinement is not a zero-sum game, pick out your combination of Single- and Multi-Team Refinement.