Sprint Planning Anti-Patterns — An Introduction
An Excerpt from the Scrum Anti-Patterns Guide (5)
Hello everyone!
Welcome to the fifth excursion into Scrum anti-patterns—the Sprint Planning.
Sprint Planning is the core event that defines how your customers’ lives will improve with the following Increment. Unfortunately, it is also prone to a large variety of issues. Learn how to improve its effectiveness by avoiding common anti-patterns, for example, not taking capacity planning seriously.
The Purpose of the Sprint Planning
Scrum’s Sprint Planning aims to align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers:
First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint.
The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish.
Next, the Developers commit to the Sprint Goal and forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. (Alternatively, they create new items.)
Also, the Developers need to plan how to accomplish their forecast. (Planning for 2-3 days into the Sprint usually suffices to start learning.)
Basically, the Sprint Planning answers three questions:
Why does this particular Sprint matter?
What is achievable in this Sprint?
How is the selected work accomplished?1
Preparing the Sprint Planning
Suppose the Scrum Team has successfully utilized the Product Backlog refinement process to create and maintain an actionable Product Backlog.
In that case, the Sprint Planning consumes much less time than the eight hours the Scrum Guides lists for a month-long Sprint. In most cases, the Developers and the Product Owner adjust the previously discussed scope of the upcoming Sprint to the available capacity.
Alternatively, a valuable new task may have appeared overnight, and the Product Owner wants this task to become a part of the next Sprint, too. Consequently, some previously considered Product Backlog items won’t make it into the Sprint Backlog. A good Scrum Team can handle that in ten to 30 minutes before moving on to the decomposition tasks and the initial planning of how the Developers intend to accomplish the work of the Sprint.
The Importance of Capacity Planning
Next to insufficiently refining Product Backlog items in advance, another critical stumbling block on the road to successful Sprint Planning is inadequate capacity planning.
At the beginning of Sprint Planning, the Developers should consider everything affecting their ability to deliver. The list of those issues is long, for example:
Public holidays,
New team members joining theScrum Team require onboarding,
Team members quitting, probably demanding a hand-over,
Team members on vacation leave or sick leave,
Previous performance,
Corporate overhead, such as all-hands-meetings,
Tools, probably in need of acquiring or updating,
Skills required to deliver the new business objective,
Dependencies on other teams or external suppliers,
Technical debt or required maintenance,
Scrum events as practices such as Product Backlog refinement,
Other events, including team-building exercises, user research during product discovery, etc.
A solid assessment of the situation and existing constraints is critical to pick an ambitious yet realistic Sprint Goal the team can deliver. Moreover, the regular delivery of valuable Increments is the foundation for building trust with stakeholders and fostering the team’s professional reputation within the organization.
Conversely, overcommitment results in undue stress, rushed work, and potential burnout, compromising quality and the ability to meet the Sprint Goal. In addition, it is likely to undermine trust with stakeholders due to the team consistently under-delivering.
While a mature team has likely built trust and gained a good understanding of everyone’s skills to handle this capacity assessment on the fly, a junior Scrum Team may require some training wheels. A fantastic tool for this purpose is a checklist.
Conclusion
The Sprint Planning is a core event, defining how your customers’ lives will improve with the next Product Increment and not be taken lightly. Fortunately, most of the beforementioned Sprint Planning anti-patterns are simple to fix. Just take them to the team, respect Scrum Values, self-management, and Scrum’s built-in checks & balances.
If you have any questions, please let me know.
Best,
Stefan
Ken Schwaber & Jeff Sutherland: The Scrum Guide — The Definitive Guide to Scrum: The Rules of the Game, 2020.