Liberating Structures for Scrum (3): The Product Backlog

6 min readJul 30, 2019

TL; DR: The Liberating Structures Product Backlog Meetup

The fourth Liberating Structures for Scrum meetup addressed the Product Backlog, more precisely the issues with Product Backlogs that subsequently cause Sprint Plannings to fail and Scrum Teams to deliver below their capabilities; as the saying goes: garbage in, garbage out.

Liberating Structures for Scrum

Created by Keith McCandless and Henri Lipmanowicz, Liberating Structures cover a set of easy to learn, yet powerful ways to collaborate as a team — even as a (very) large team by Scrum standards — , overcoming traditional communications approaches like presentations, managed discussions, or another disorganized brainstorming at which the loudest participants tend to prevail.

Liberating Structures are well suited to improve the level of engagement among participants of Scrum events, thus stimulating the kind of outcomes that are necessary to create learning organizations. Liberating Structures also provide an excellent toolbox to handle Product Backlog refinements or improving the Definition of Done of an engineering organization.

Lastly, Liberating Structures are a great tool when large groups come together for retrospectives, self-selection of teams, or figuring out where to go next; which is what the Product Backlog is all about.

See the slidedeck for the meetup here.

Download the Agile Transition Guide

The free “Agile Transition — A Hands-on Guide from the Trenches” ebook is a 266-pages strong collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people strong to agile practices.

The Product Backlog

The Product Backlog is one of the three Scrum artifacts and reflects at any moment the best possible use of the Development Team’s time. According to the Scrum Guide:

The Product Backlog is an ordered list of everything that is known to be needed in the product
It is the single source of requirements for any changes to be made to the product
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases
A Product Backlog is never complete
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog
This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Source: Scrum Guide.

The conclusion of the previous meetup on Liberating Structures for the Sprint Planning was obvious: successful Sprint Plannings depend on a well-prepared, actionable Product Backlog where the Scrum Team managed the heavy lifting already during the Product Backlog refinement. Hence the goal of this meetup was to figure out a way to create a well-prepared, actionable Product Backlog utilizing Liberating Structures.

In that regard, we were particularly interested in the three issues that form the messy middle of any Product Backlog:

The process of identifying potentially valuable new functionality and necessary work items. Are features “requests” still handed down from the “business” to “IT” along with the my-budget-my-feature thinking that tends to result in local optimizations?
What items belong to an existing Product Backlog? For example, how is the Product Backlog reflecting non-functional items to improve the quality of the tech stack?
Finally, how does the Scrum Team handle the Product Backlog refinement? Is it a Jira-driven exercise to tick boxes on a check-list? Alternatively, is the Team having an open discussion in which the Product Owner pitching the ‘why,’ the Development Team deciding on the ‘how,’ and both meeting in the middle to haggle on the ‘what?’

If you enjoyed the article, do me a favor and smack the 👏👏 👏 multiple times — your support means the world to me!

If you prefer a notification by email, please sign-up for my weekly newsletter and join 23,113 peers.

Liberating Structures Product Backlog: Ecocyle Planning

The Ecocyle Planning

The subtitle of the Ecocycle Planning page summarizes the potential of this microstructure well:

Analyze the Full Portfolio of Activities and Relationships to Identify Obstacles and Opportunities for Progress.

In my experience, Ecocycle Planning has proven to be a powerful tool for Product Owners and Scrum Masters alike when a Scrum Team needs to deal with a suboptimal Product Backlog. It can be used as an instrument to understand whether the content of the Product Backlog still reflects the best use of a Scrum Teams time. Moreover, Ecocycle Planning can be applied to identify processes and practices within the organization that prevent Product Backlogs from achieving their full potential.

The Exercises with Ecocyle Planning

As a first exercise, given the diversity of participants at the meetup, four groups practiced the Ecocycle Planning by creating a (meta-level) list of activities, practices, and relationships that helped shape the participants’ professional status today.

While this exercise was working reasonably well, I consider addressing this career question later in 2019 in a separate meetup, the final exercise of the day had room for improvement in hindsight. The four groups were tasked with identifying emergency procedures to turn a weak Product Backlog into an actionable one by designing a string of Liberating Structures that they could act on in the short-term.

In the end, one group suggested a Liberating Structures string, comprised of the following microstructures:

The group suggested to use 1–2–4-All to aggregate individual findings in the process.

Conclusion

Ecocyle Planning is a powerful forensic tool to identify waste, bottlenecks, anti-pattern, and impediments within your organization and your Product Backlog. Practice it in a smaller group setting before rolling it out as your facilitation tool of choice to the rest of the organization. Allocate sufficient time to exercises based on Ecocyle Planning; proper execution with starters to Liberating Structures likely takes much longer than the estimated duration of 95 minutes.

What problems did you solve with Ecocycle Planning? Please share with us in the comments.

Liberating Structures Immersive Workshop — Related Posts

Liberating Structures for Scrum (1): The Sprint Retrospective.

Liberating Structures for Scrum (2): The Sprint Planning.

✋ Do Not Miss Out: Join the 5,750-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.