What is a Sprint Planning in Scrum?
A sprint planning event is simply all about planning a sprint. The purpose is to define what can be delivered in the sprint and how that goal will be achieved. It is the first event of the sprint. The outcome of this event is a sprint backlog which contains a sprint goal. Sprint planning is essential in Scrum. Why? A sprint planning event tries to answer the following topics.
What Makes a Sprint More Valuable?
In sprint planning, the product owner (PO) proposes how to increase the value and utility of the product through the current sprint. The primary tool that a product owner has is the product backlog item (PBI). It can include user stories, epics, specifications, bugs, or change requirements. The PO compiles and prioritizes them by putting the most urgent PBI at the top. By doing this, PO decides which items are more useful and generate more value to the product. The priority list will make product development clearer and more actionable. The most important thing in this process is to let the team know what will be done next.
In sprint planning, the scrum team also defines a sprint goal. It includes the objective that the team should achieve during a sprint. It is a crucial element of the sprint plan that will help the team and stakeholders to work more effectively, focused and aligned. That is why a sprint goal must be specific, measurable, and flexible. It was defined by the entire scrum team, not only the product owner. At the end of the meeting, the sprint goal must be defined and everyone should have a clear understanding of what the sprint is trying to achieve. All the processes will make each sprint more valuable and be a step toward reaching the product goal.
What can be Done in this Sprint?
By understanding the sprint goal and collaborating with the product owner, developers will forecast what can be done in the sprint. What is a forecast? Let’s think about a weather forecast. You are probably looking at your phone’s weather app to see how hot or cold it is outside and whether you need to carry an umbrella. Most of the time the forecast will roughly match the reality. But once in a while, the weather app on your phone maybe announced a sunny day, when in fact you got clouds and maybe some rain out there. This is what the forecast is. You are never 100% sure. Nobody guarantees it.
Forecasting scrum is very similar to this. It should never be confused with a guarantee or a commitment. The forecast represents the PBIs selected by the developers as they think they can finish it by the end of the sprint. Why do they need to select them? Indeed, a product owner can decide which work will be done. But they can’t decide the amount of work the developers will do. Selecting how many items can be completed within a sprint may be challenging. However, the more the developers know their past performances, their upcoming capacities, and their “definition of done”, the more confident they will be in forecasting their sprint.
How will the Chosen Item Get Done?
The sprint goal has been defined and the PBI for the sprint has been selected. In the following process, the developers discuss how the functionality will be built into a product increment. In scrum, a product increment is whatever you previously built, plus anything new you just finished in the latest sprint, all integrated, tested, and ready to be delivered or deployed. It is the phase to deliver the product value and to get real user feedback to ensure customer satisfaction.
Only the developers can decide how to plan and do their work. This is often done by decomposing PBIs into smaller work items of one day or less. How the work items will be executed is at the sole discretion of the developers. The breakdown work or task is not part of the PBI, but part of the sprint backlog. This is the plan for implementing PBI. This is the way to get things done.
*This article is written by Lydia Liliana, a Scrum Master
References:
https://scrumguides.org/scrum-guide.html
https://www.atlassian.com/agile/scrum/sprint-planning
https://resources.scrumalliance.org/Article/product-increment
