Making Your Sprint Planning Events More Effective
Antipatterns
The purpose, timebox and participants of Sprint Planning are well defined. However, we sometimes see Scrum Teams fall into antipatterns that diminish their value.
Participants not fulfilling their accountabilities correctly:
- Unavailable Product Owner - If the Product Owner, or their delegate, doesn’t participate in Sprint Planning, the Developers must step in and based on their understanding fulfill all the accountabilities of the Product Owner. Unfortunately, they are unlikely to have all the information a Product Owner has that allows them to determine what makes this Sprint and each Product Backlog Item more valuable relative to others on the Backlog. This situation puts undue burden on the Developers and the stakeholders and may result in the wrong product being developed.
- PBIs and Sprint Goal are selected by the Product Owner with no conversation about the value of the work - In the course of implementing a PBI, Developers may make countless decisions and tradeoffs. Without understanding the value of what they are creating, they are likely to make bad decisions.
- Only the team lead or a trusted, “core” team provides estimates. Scrum believes that the team is stronger together and strong estimates take into consideration all team members’ viewpoints, knowledge and expertise.
- Pulling in too much work or Product Owner tells the Developers what work to pull into the Sprint - Developers that do not determine what work can be accomplished during the Sprint are not fulfilling their accountabilities.
Backlog or Participants are Not Prepared for the Event:
- Lack of Product Backlog Refinement - Without adequate Refinement, the Developers make assumptions such as: the value of each PBI; what the stakeholders are asking for and why they are asking for it; the acceptance criteria for the PBI; and their ability to complete the work on each PBI in one Sprint. This puts the success of the Sprint in jeopardy.
- Ambiguous Requirements - If the PBIs do not have sufficient information for the Developers to understand what is being requested, it is likely that the result of their work will not fulfill the stakeholders’ desires, wasting everyone’s time.
- Having undone work at the end of a Sprint - Overestimating what work can be completed during the Sprint is a sign that the PBIs aren’t sufficiently defined, the team has a poor assessment of their capacity or the Definition of Done is overly restrictive for the current state of the product
- Work is broken down and estimated in this event - A strong Scrum Team regularly refines their backlog which includes estimating and breaking down the work
- Sprint Planning takes too long - The more familiar the team is with the Backlog, through regular refinement meetings and a defined definition of ready, the more efficient and effective these meetings are. Sprint Planning meetings which are long, are often not well planned or facilitated.
Purpose of the Event not fulfilled:
- Erroneous Forecasts - Developers are asked to forecast what work can be done in a Sprint and Scrum Teams are often asked to forecast when some part of the product will be available for use. Scrum Teams that do a poor job of Sprint Planning usually are unable to create reliable forecasts.
- No Shared Commitment or Unclear Sprint Goal - Sprint Goals are designed to get the team focused around a singular outcome. If the team isn’t committed to the same outcome, it’s likely that the Sprint Goal isn’t well defined.
- Team talks more about velocity than value - Velocity is a measure of how much “stuff” is produced, regardless of its value. Purpose of the Sprint is to create value, not execute a high volume of tasks.
- Testing is not complete by the end of the Sprint - If the testing that is required by the DoD is not complete at the end of the Sprint, the work is not Done. The team is either ignoring their DoD or they are overestimating the work they can execute.
- Teams don’t start work on the selected PBIs until all the work for the Sprint is defined. It is okay if there are still unknowns during/after this event, the team starts with what they know and defines more of the unknowns during the Sprint.
Tips for Strong Sprint Planning
Breaking the antipatterns listed above help create strong and effective Sprint Planning events. Consider the following tips:
- Developers ask questions until it is clear how each PBI creates value or is useful to the customer
- Developers ask questions until they have a good sense of how they will implement the PBIs
- Scrum Teams collaborate on solving problems together
- Scrum Teams use metrics as criteria for selecting the amount of work selected for the Sprint
- Scrum Teams understand all the work needed to create an Increment that adheres to their Definition of Done and uses this understanding to help them with capacity
- Scrum Teams devise strategies that enable multiple team members to focus on a PBI
- Scrum Teams focus on strategies that enable the lean principle of “just enough”
- Scrum Teams add improvement items to the Sprint that were uncovered by a previous Sprint Retrospective
Resources:
What did you think about this content?
Included In
Learning Series
Every Sprint starts with Sprint Planning where the Scrum Team determines what they plan to accomplish during the course of the Sprint. They make this transparent by creating a Sprint Backlog including the Sprint Goal, the selected Product Backlog Items and the Developers’ plan for delivering the work