Improving Scrum Sprint Planning With Liberating Structures

DZone 's Guide to

Improving Scrum Sprint Planning With Liberating Structures

If your sprint planning isn't as productive as it should be, Liberating Structures can help.

· Agile Zone ·
Free Resource

Sprint planning

Is it time to liberate your Scrum team?

According to creators Keith McCandless and Henri Lipmanowicz, Liberating Structures "are easy-to-learn microstructures that enhance relational coordination and trust. They quickly foster lively participation in groups of any size, making it possible to truly include and unleash everyone. Liberating Structures are a disruptive innovation that can replace more controlling or constraining approaches."

It probably goes without saying, then, that they are particularly well suited to improve the level of engagement among participants of Scrum events. While my last post discussed their use in Sprint Retrospectives, this post one dives into another often problematic event: Spring Planning.

You may also like:  Upgrade Your Sprint Planning, Gain Engagement From Your Development Team

The Sprint Planning

To review, 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?

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 as 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 does this happens so 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.

Liberating Structures for Scrum Sprint Planning — Hands-on Agile

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

Reasons Why Sprint Plannings Fail

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:

Team 4:

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

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 had already managed the heavy lifting during the Product Backlog refinement. 

You may also like:  When Product Backlog Is a Mess

Which 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 "must dos" and "must not dos" that would deliver the objective.

The Team Results for Min Specs 

These are the results the teams came up with:

Team 1:


  • 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’t specify solutions (features)

Team 2:


  • 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
    • Not too much detail in the future
    • Too many Product Backlog items (50-plus)
    • Estimate after one another

    Team 3:


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


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

    Liberating Structures for Scrum Sprint Planning — Min Specs

    Conclusion: Liberating Structures in Sprint Planning

    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!

    Further reading

    6 Tips to Boost Team Motivation for Your Agile Team

    How to Have Efficient Sprint Planning Meetings

    The Good, the Bad, and the Ugly Backlog

    scrum ,sprint planning ,liberating structures ,scrum master ,product backlog ,efficient meetings ,engagement

    Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.

    Opinions expressed by DZone contributors are their own.

    {{ parent.title || parent.header.title}}

    {{ parent.tldr }}

    {{ parent.urlSource.name }}