Improving Scrum Sprint Planning With Liberating Structures
If your sprint planning isn't as productive as it should be, Liberating Structures can help.
Join the DZone community and get the full member experience.Join For Free
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:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- 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.
Reasons Why Sprint Plannings Fail
- Skill (experience) deficiencies
- Unclear Sprint Goal (priorities)
- Stories not ready (prioritization, refinement)
- Push, not pull
- The ‘Why’ is not clear
- Poorly refined (Product) Backlog
- Team structure (e.g., no back up)
- Unclear dependencies
- 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:
- Product Backlog items for Sprints meet Definition of Ready
- Product Backlog items meet INVEST criteria
- Clarify outcomes
- Refine items for clarity & understanding
- Refine continuously
- Don’t specify solutions (features)
- 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
- Meets Definition of Ready
- Enough items for Sprint
- Refinement last minute
- Don’t over-refine the future
- Ignore dependencies
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!
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.