What is a Sprint Planning?
The Sprint Planning is the first activity of every Sprint in Scrum. During the Sprint Planning, the entire Scrum Team collaborates on what will be delivered in the next sprint, how it will be delivered and why this is the right thing to work on during the sprint.
The result of the Sprint Planning is a clear understanding of the sprint goal together with a sprint backlog containing refined work items and a plan on how to approach the work.
According to the Scrum Guide, the Sprint Planning could take up to 8 hours for a sprint of one month. In practise, we suggest taking the time you need to create a proper plan for the sprint since it depends per team/product. If you need a lot more time, this might be an indication of gaps within your process.
Why should we do Sprint Planning?
The Sprint Planning creates clarity and transparancy, gives direction to the team and sets the expectations for the sprint.
Who should be involved in the Sprint Planning?
The entire Scrum Team should be present during the Sprint Planning. Additional stakeholders can be invited if needed. When one or more members of the Scrum Team are unavailable during the Sprint Planning, we introduce the risk of creating an unrealistic or incorrect plan.
Topic One: Why
First, the team decides why the sprint will be executed. What’s the value of the sprint, how will we increase the value of the existing product or service?
Usually, the Product Owner proposes how the value of the product or service can be increased during the sprint. Based on this, the team will collaborate on a goal for the next sprint: the Sprint Goal. This goal summarizes the value that the sprint will bring, and gives direction for the sprint.
Topic Two: What
The next step is to determine what will be delivered in the current sprint so we can achieve the Sprint Goal. Based on the Sprint Goal, the team will collaborate on which items should be selected from the Product Backlog so that the Sprint Goal can be realised. New work items are created if needed. The selection of work items from the Product Backlog will result in the Sprint Backlog.
So, how do you know which work items you should select, and how many you can select?
Each work item, often defined as User Stories, should clearly state the result and added value that it will bring together with the effort to implement it. Based on our Sprint Goal, we can select work items that contribute to the Sprint Goal.
Next to that, the team should know how much work it can pick up in the Sprint. This can be achieved by looking at the average velocity and available capacity in the current sprint. Some additional refinement might be needed to ensure that all work items are clear and achievable.
This step requires collaboration from the entire Scrum Team.
Topic Three: How
When we have a clear Sprint Goal (“why”) and we know which work items we should implement to achieve this (“what”), it is time to look at how we will do this. The team creates a plan on how to achieve the selected work.
In this stage, the practical plan for the sprint is created by the team. We should look at the (technical) implementation of each work item, to the impact on the already existing solution, who will work on which items, if we have dependencies with external parties, other teams or other work items and so on.
The goal of this stage is to create clarity on how the work will be implemented during the sprint, what is needed for this, and what needs to be taken into account. After this stage, the team should be able to start the sprint.
It’s important to consider the Definition of Done in this step as well. Everything that needs to be done in order to meet the Definition of Done must be discussed.
So, what is a "plan"?
Each team will take specific elements into account while creating a plan for the sprint. Some general elements that you can include are the following:
It can be valuable to create a checklist of what needs to be covered during the sprint planning. When you identify gaps during your sprint (e.g. the team forgot to identify a dependency to another team during the sprint planning, causing certain work to be blocked or delayed because the other team has not taking this work into account in their sprint), you can add this to the checklist and make sure the team identifies this during the next sprints.
Recent comments