Liberating Structures for Scrum: The Sprint Planning

TL;DR: Liberating Structures for Scrum: The Sprint Planning

The fourth Liberating Structures Scrum meetup addressed the Sprint Planning, more precisely the reasons why Sprint Plannings fail—despite all the efforts put into them in advance, from the Product Backlog refinement to the Sprint Review.

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.

The Sprint Planning

The purpose of the Sprint Planning is to plan the work for the upcoming Sprint in a collaborative effort of the complete Scrum Team. 

There are two main topics that the Scrum team will address. According to the Scrum Guide, the Sprint Planning answers two questions:

1. What can be delivered in the Increment resulting from the upcoming Sprint?
2. How will the work needed to deliver the Increment be achieved?

Source: Scrum Guide.

In my experience, an experienced Scrum Team will seldom run into trouble figuring out how to deliver value to the customers. A lot of careful preparation leads to the Sprint Planning, for example, the Product Backlog refinement as an ongoing process, or the Sprint Review. 

Given the right level of transparency and collaboration, the Sprint Planning will, in most cases, confirm what the Scrum team has used a hypothesis in the weeks leading up to the Sprint Planning. So far, so good—there is not much need to apply the might of Liberating Structures as a collaborative decision enabler.

And then there are the cases where the Sprint Planning goes awry. Where the Scrum Team is not able to turn a business objective into a Sprint Goal that can be accomplished by implementing a set of Product Backlog items.

The question is, why this happens that late in the process?

There are numerous Sprint Planning anti-patterns, but the one that comes to mind quickly is best described as “garbage in, garbage out.” Therefore, the first task for the four teams was to identify the most likely causes for failure during Sprint Planning, utilizing the 1-2-4-All microstructure.

The Scrum Anti-Patterns Guide

This ebook covers over 160 Scrum anti-patterns, and it is available for free right here.

Download the “The Scrum Anti-Patterns Guide” now!

Reasons Why Sprint Plannings Fail

During the 1-2-4-All exercise, all four teams came to a very similar root cause: “It’s the Product Backlog, stupid!”

Team 1:

• Skill (experience) deficiencies
• ??Preparation
• Unclear Sprint Goal (priorities).

Team 2:

• Stories not ready (prioritization, refinement)
• Push, not pull
• The ‘Why’ is not clear.

Team 3:

• Poorly refined (Product) Backlog
• Team structure (e.g., no back up)
• Unclear dependencies.

Team 4:

• Product Backlog not ready
• Sprint Backlog not achieved
• Team issues: tensions, no matching objectives, tickets instead of goals.

Conclusion: What Optimizes the Probability of Successful Sprint Planning?

The findings of the four teams were similar: 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. 

Which lead us to the next task: figure out what it takes to create a well-prepared, actionable Product Backlog.

Min Specs for Well-prepared, Actionable Product Backlogs

The second task of the evening—identifying the prerequisites of actionable Product Backlogs—led us to a new Liberating Structure microstructure: The Min Specs. The purpose of the Min Specs is to strip down processes and practices to the bare minimum that would deliver the objective:

“What is made possible? By specifying only the minimum number of simple rules, the Min Specs that must ABSOLUTELY be respected, you can unleash a group to innovate freely. Respecting the Min Specs will ensure that innovations will be both purposeful and responsible. Like the Ten Commandments, Min Specs are enabling constraints: they detail only must dos and must not dos. You will eliminate the clutter of nonessential rules, the Max Specs that get in the way of innovation. Often two to five Min Specs are sufficient to boost performance by adding more freedom AND more responsibility to the group’s understanding of what it must do to make progress. Out of their experience in the field, participants shape and adapt Min Specs together, working as one. Following the rules makes it possible for the group to go wild!”

Source: Liberating Structures: Min Specs — Specify Only the Absolute “Must dos” and “Must not dos” for Achieving a Purpose (35-50 min.) 

The Team Results for Min Specs for Well-prepared, Actionable Product Backlogs

These are the results the teams came up:

Team 1:

Dos:

• Product Backlog items for Sprints meet Definition of Ready 
• Product Backlog items meet INVEST criteria 
• Clarify outcomes
• Refine items for clarity & understanding
• Estimate
• Refine continuously

Don’ts:

• Don’t specify solutions (features)

Team 2:

Dos:

Relentlessly prioritize

Keep tickets up to date

DoR (Definition of Ready)

Business value.

Don’ts:

• External interference into POs sole ownership of the Product Backlog
• No too much detail in the future
• Too many Product Backlog items (50-plus)
• Estimate after one another.

Team 3:

Dos:

• Meets Definition of Ready
• Prioritized
• Enough items for Sprint.

Don’ts:

• Refinement last minute
• Don’t over-refine the future
• Ignore dependencies.

Typically, we would have aggregated the team-findings into a group result. Due to the lack of a suitable surface, we skipped this part, however.

By the way, if you are missing the result of the fourth team, I miss it, too. ???♂? 

Conclusion: Liberating Structures Sprint Planning

Liberating Structures strings work wonders if you need to address critical issues that require inclusion and giving everyone a voice in a safe environment. This approach even works in settings where the seeds of failure have been planted before. The four teams rightfully concluded that a successful Sprint Planning mainly depends on an actionable Product Backlog, and hence continued exploring the minimum requirements of those applicable to most Scrum Teams.

What experiences have you made using Liberating Structures to enhance Scrum events? Please share with us in the comments.

The next article on Liberating Structures for Scrum will address Product Backlog refinement. Stay tuned!

?? Join 1,450-plus Agile Peers on Youtube

Now available on the Age-of-Product Youtube channel:

• Scrum Sprint Retrospective Anti-Patterns.
• Scrum Master Anti-Patterns.
• Scrum Sprint Anti-Patterns.

? Do Not Miss Out: Join the 5,450-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.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

?? Do You Want to Read more like this?

Well, then:

• ?? Join 22,363 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Alternatively, join 5,450-plus peers of the Slack team “Hands-on Agile” for free.

Liberating Structures for Scrum (2): The Sprint Planning was first published on Age-of-Product.com.