We will endevour to explain not just the purpose of Sprint Planning but the additional practices and understanding that are required to make it effective. We will also look at how to market the outcome and help teams to communicate their intentions and plans to stakeholders so that they can support the team in their work.
The purpose of Sprint Planning is to create a plan for the Sprint. The entire Scrum Team attends as well as anyone they deem necessary to help them. While there is a maximum of 8h for this event the greater the degree of understanding tha the Scrum Team has going in the shorter it will be. That is, if the Product Backlog is well understood, and the Product Goal is clear, then the Sprint Planning will be short. If the Product Backlog is not well understood, or the Product Goal is not clear, then the Sprint Planning will be longer.
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.
> Scrum Guide
I would expect a typical Sprint Planning to take from 30-120 minutes is there is clear understanding.
See Sprint Planning Recipe for look at how Sprint Planning might run.
The Sprint Planning is where the initial transparency of the Sprint Backlog emerges.
Part of Sprint Planning is to create a Sprint Goal. The Sprint Goal is a short statement that describes what the Scrum Team intends to achieve in the Sprint. It is a commitment by the Scrum Team to the stakeholders. It is a marketing statement that helps stakeholders to understand what the Scrum Team is doing and why. It is a statement that helps stakeholders to understand how they can support the Scrum Team in their work.
The Sprint Planning event is a planning event. It is where the Scrum Team plans the work that they will do in the Sprint. It is where they create the Sprint Backlog. This plan is a forecast of the work that the Scrum Team believes they can complete in the Sprint. It is a forecast because it is based on the current understanding of the Product Backlog and the current understanding of the Scrum Team’s capacity and capability.
Many Scrum Teams lament on the fact that they are not able to get the support they need from stakeholders. This is often because they have not communicated their intentions and plans to stakeholders in a way that they can understand.
The Scrum Team should be aware of the external stakeholder view of the Sprint Goal and what they are working on and deliberately craft this to engage stakeholders and help them to understand how they can support the Scrum Team in their work.
If this means working on somethign other than the highest priority item in the Product Backlog then that is fine as long as it serves the purpose of maximizing the value of the work done by the scrum team.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
CR2