Liberating Structures for Scrum (2): 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:
What can be delivered in the Increment resulting from the upcoming Sprint?
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.
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!
Liberating Structures Sprint Planning — Related Content
Liberating Structures for Scrum (1): The Sprint Retrospective.
Liberating Structures for Scrum (3): The Product Backlog.
Upcoming Liberating Structures Workshop
📅 🎓 Berlin, February 18-20, 2020: Professional Scrum Training plus Liberating Structures — three immersive Days for Scrum Masters .
📅 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.
Tags: Liberating Structures, Scrum, Sprint Planning