Liberating Structures for Scrum (2): The Sprint Planning

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

The third 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.

🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.

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.

Cannot see the form?
Please click here

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.

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.

This leads 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!

Attribution

Liberating Structures are developed by Henri Lipmanowicz and Keith McCandless and are licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

📺 Join 1,400-plus Agile Peers on Youtube

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

• Agile Maturity and Agility Assessment: Is Agile a Fad or Trend?
• Agile Failure Patterns 2.0
• Product Owner Anti-Patterns

📖 Liberating Structures Sprint Planning — Related Content

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

📅 Scrum Training Classes, Workshops, and Events

You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:

See all upcoming classes here.

You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.

✋ Do Not Miss Out and Learn more about Liberating Structures Sprint Planning: Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team 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.