Product Backlog Refinement with Liberating Structures

A path for coaching your team about the importance of refinement and improving refinement activity

Alessandro Zanetti
Serious Scrum
7 min readMar 17, 2021

--

Product Backlog refinement is not always a loved activity, especially at the beginning of the Scrum journey. This article tries to give a path for coaching your team and for having more fun and effectiveness during this activity.

Photo by Tim Gouw on Unsplash

And why not using Liberating Structures for reaching this goal?

Liberating Structures

Self-managing teams know that they would greatly increase productivity and innovation if only they could get everyone fully engaged. The challenge is how to do it. Liberating Structures are practical methods to help you accomplish this goal with groups of any size.

Liberating Structures are a set of 33 micro-structures designed to replace the ineffective formats in which groups dissect information, make decisions, and explore new ideas.

Rather than actively involving only a handful of those present, and drowning out other voices, Liberating Structures allows everyone to be equally involved in shaping future actions.

Rather than focusing on individuals, Liberating Structures taps into the wisdom and creativity of the entire group.

Types of meeting, depending on people inclusion and content controlling

The purpose of refinement

What happens when your team members skip or are unwilling to participate in a meeting? What happens when your team members are bored during a meeting?

It happens that your team morale starts to suffer and at the end your product. So as Scrum Master start to coach your Scrum Teams about the importance of the refinement activity, going back to the basics and illustrate that:

As an activity, Product Backlog refinement has the following purposes in Scrum:

Clarifying items on the Product Backlog that are too unclear to start work on.

Breaking down items that are too big to pull into a Sprint (which generally also means that they’re too unclear).

Re-ordering the Product Backlog as needed to make the upcoming Sprints as smooth and valuable as possible.

Adding or removing items from the Product Backlog as new insights emerge.

Sizing the effort needed for implementing particular items.

But if this frontal way of presenting is not enough and your refinement activity is far from what you desire to be, stop counterproductive actions, and give the team the possibility to find their way for doing refinement.

Setting up a workshop and following this string of Liberating Structures is worth a try:

• Starting with “TRIZ”, the team can understand what can happen if a bad refinement is made

• Following with “Min Specs”, the team can give themselves the minimum rules for making a good and interesting refinement

The “TRIZ+Min Specs” String

Steps to facilitate TRIZ

Make clear we are concentrating on the past (and not the future) and we are not searching for solutions

1) Each participant should make a list of all she/he can do to make sure that the worst refinement event can be achieved (10 min).

2) Go down this list item by item and ask yourselves, ‘Is there anything that we are currently doing that in any way, shape, or form resembles this item?’ Build together a second list of all your counterproductive activities and procedures. By using the structure “1–2–4-ALL”, give everyone a minute to get their own thinking started in silence (1 min), then pair up with someone else to build on their ideas (2 min) and paired with another pair (4 min). Ask the groups of four to write their questions down on an index card. If you have many groups, you can ask them to limit to one or two questions.

3) By using “1–2–4-ALL”, go through the items on your second list (containing all your counterproductive activities and procedures) and decide what first steps will help you stop what you know creates undesirable results.

Don’t accept ideas for doing something new or additional: be sure suggestions are about stopping activities or behaviors, not about starting new things. This will be done in “Min Specs”.

Steps to facilitate Min Specs

1. Have people organize in groups of 4.

2. Introduce the challenge, like ‘What is needed from us to have a creative refinement event.

3. Ask people to individually write down as many must-do- and must-not-do activities as they can in a couple of minutes (2 minutes).

4. Ask the groups to consolidate their individual lists, and expand them to be as complete as possible (Max Specs) (5 minutes).

5. Ask the groups to aggressively test all the items on their lists against the challenge. Can the purpose still be achieved without this item? If so, remove the item (15 minutes).

6. Compare across the small groups and consolidate them together to the shortest list possible. Discuss the final list (15 minutes).

At the end of the workshop

At the end of the workshop, you will have a working manifesto that helps you and the team to have common rules and understandings about the refinement activities.

This can be used as a kickoff for this activity; now let´s see how the refinement activity could be addressed.

The refinement meeting in a “traditional” way

A lot of Scrum Teams meet during the sprint for refining Product Backlog Items together.

As Scrum Master and facilitator, at the beginning of the meeting refresh the agreed ways of working that have been found together with “Min Specs”, and also follow them during the meeting.

During the meeting, remember the unwanted behaviors that have been found with “TRIZ” and make sure it is stopped. Especially the first times it’s easy to repeat the old habits and identified dysfunctions.

If you’re breaking down challenging items, you can use the following Liberating structures:

· 1–2–4-All, especially for product backlog items that interest the whole team or/and are in an early stage of knowledge

· Troika Consulting, especially for product backlog items that interest a small number of developers

The refinement meeting “without refining”

Not all activities related to refinement are ideally suited to do with the whole team. The breaking down or clarification of items, for example, can be done by varying subgroups in the team that then converge back to the team.

Breaking down items is often a complicated activity requiring significant creativity and time to think things through. Meetings are often not the best environment to do this kind of heavy mental weightlifting.

Sitting down around a conference table in a meeting room is not a very engaging way of doing complex work.

Many teams can benefit from a Diverge-Converge Pattern, described in detail in this article “Myth 14: Refinement is a required meeting for the entire Scrum Team”. As a team, decide which items need to be clarified or broken down and who wants/needs to be involved. The smaller groups then do this work during the Sprint or during ‘Breakouts’ (Diverge) and share their results with the Scrum Team at a later moment during the Sprint to decide on the next steps together (Converge).

Other activities, like estimation or re-ordering of the Product Backlog, can then be done together based on what was learned during refinement.

Diverge/Converge: a practical example

Based on my experience a good approach could be as follow: once per sprint a refinement meeting is planned and has 2 goals:

• Developers self-assign Product Backlog Items in “Open” status for refinement until the next refinement meeting

• The whole Scrum Team check if Product Backlog Items in “Refined” status can switch to “Ready” status, by using the “Definition of Ready” that team has developed itself

Example of a Definition of Ready

During the Sprint, subgroups of developers meet in a self-organized way and refine Product Backlog Items.

Conclusion

Experiment with what works for your team. For some teams, doing refinement together is the best way. For others, the above solutions may be more helpful. It depends on the size and experience of the team members and the composition of the team.

What is important, experiment with new ways of working and then inspect and adapt!!

Special thanks

Special thanks to Christiaan Verwijs and Barry Overeem from The Liberators, that inspire my workshops with their meetups, articles, and strings of Liberating Structures.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Thanks to Roy Klein, Fredrik Carleson, Sjoerd Nyland, Kunal Shah and Leise Passer Jensen.

--

--

Alessandro Zanetti
Serious Scrum

Enthusiastic Scrum Master (PSM II, SPS, PSPO I) and R2M Trailblazer on the road to Agile Coach. I talk about Scrum, Agile, and Liberating Structures.