Don’t Sprint through Sprint Planning!
This is the third post in our Scrum Assessment Series. Too many teams we observe are trying to get out of their Sprint Planning meetings as fast as possible. They think the goal is to just get a plan. Some cheat by having everyone task their work ahead of time or skip the tasking altogether. They are missing the point!
The goal of Sprint Planning is to not only get the plan created but also to develop a shared commitment to that plan. The only way we can have a shared commitment is if the whole team understands the work. Sprint Planning is just as much about knowledge development as it is about creating a plan. In order to effectively break down the work, the team needs to share knowledge and discuss the information at hand until it is understood by all.
You can use the following questions to assess how effective your Sprint Planning sessions are:
- Is everyone required to get the work done in attendance?
- Is the Product Owner available to answer scope clarification questions?
- Is a backlog provided by the Product Owner?
- Is that backlog clearly prioritized?
- Does the team have clarity on scope?
- Does the team have clarity into the work required to complete the scope (i.e. tasks)?
- Is the work estimated?
- Is the team aware of their capacity for the sprint and taking that into consideration as they create the sprint plan?
- Does everyone have an idea of tasks they may work on?
- Was the meeting roughly 2 hours per week of the sprint?
- Did the team break the stories down into small incremental chunks of work?
- Were the stories discussed prior to Sprint Planning in a Backlog Refinement session to prevent surprises?
- Are all the items the team pulls into the sprint considered “ready”?
- Were the stories well understood before Sprint Planning?
- Does the team have a shared goal?
- Is the team fully committed to completing the scope?
- Did the team leave some tasks unassigned so that there’s an opportunity for swarming?
- Was there knowledge transfer to support shared ownership?
- Were tasks broken down to a day or less of work?
- Were risks considered?
- Were dependencies considered?
- Are there very few surprises?
- Does the team commit without a lot of risk or unknowns?
- Are there very few outside dependencies?
- Was some high-level design considered?
- Does the team own the session, requiring minimal guidance?
- Does the team spend some time before Sprint Planning making sure they are “ready” to work on the new stories? (i.e. gained knowledge, secured necessary environments, mitigated dependencies, etc.)
- Does the team have a game plan for how to get the work done?
- Can everyone on the team articulate the sprint goal?
Here are some ideas you can implement to help improve your Sprint Planning:
- Setup a Backlog Refinement Meeting cadence for the team to discuss upcoming stories with the Product Owner to ensure the stories are ready.
- Consider defining a “Definition of Ready” for your stories so the team and Product Owner’s expectations are aligned on what needs to be done prior to Sprint Planning.
- Make sure the team is discussing what will be involved to get the work done. If someone is unfamiliar with the work area then have a more experienced person explain it. Knowledge transfer during Sprint Planning will lead to better swarming during the Sprint.
- Break the work down into tasks that take no longer than a day.
- Reserve more time than you think you’ll need for the Sprint Planning meeting so the team does not feel rushed.
- Have everyone work together to break down work.
- Conduct a Fist of Five poll after each story is planned to ensure that the team is comfortable with the commitment.
View other posts in our Scrum Assessment Series.
What items have you implemented that improved your Sprint Planning?