Learn the secrets to the crucial part of the Scrum methodology and use our template for it.
How to Master Sprint Planning and Run It Like a Pro?
Speaking about the sprint planning, let's define what is a Sprint first. The sprint is a time-boxed iteration of a continuous development cycle. The duration of the sprint is one month or less, and during that time, a planned amount of work has to be completed by the team.
A sprint consists of the Sprint Planning, daily stand-ups or scrums, development work, the Sprint Review, and the Sprint Retrospective. A new sprint starts immediately after the conclusion of the previous sprint.
What is sprint planning?
Sprint planning was created as a part of the Scrum framework and is considered as one of its original events. During this event, all the work for the sprint is planned, and the sprint goal is set. The planning session kicks off the sprint by setting the agenda and focus. Sprint planning is time-boxed to a maximum of eight hours for a one-month sprint.
The event is shorter for shorter sprints, as it is demonstrated in the table below.
What are the advantages
of sprint planning?
One of the main advantages of sprint planning is that the team comes together in one place and gets a shared understanding of what they will work on during the next sprint. They will already have an initial action plan before a new iteration starts. Sprint planning enables the team to agree on the sprint goal and commitment. This event creates a platform to communicate dependencies and identify team capacity. The most important advantage is that a good sprint plan motivates everyone by defining an outcome and a clear plan to follow. It also creates an environment where the team is excited and challenged to reach common goals.
Who is involved
in sprint planning?
Usually, the entire team is involved. The team members plan how many items of the product backlog they will be able to complete and how they will deliver those items. The product owner must be prepared to set the right scene for the sprint, taking into account the lessons learned from the previous sprint review. He has to describe the highest priority features to the entire team. Then the team discusses which stories they will take on. A scrum master has to ensure that the discussion is effective and that all attendants understand the purpose of the event. He/she is responsible for making sure that the meeting happens within its time box.
Part one:
What?
The first part of the sprint planning should be focused on the sprint objective, rather than on the details of the product backlog. During the first part of the sprint planning, the team selects the ready product backlog items. The team members forecast what they will be able to complete during the sprint. The product owner has to describe what he/she wants to get by the end of the next sprint. The team and the product owner collaborate to determine what functionality can be delivered in the upcoming sprint. The team should ask enough questions so that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. By the end of the first part of the sprint planning, the goal or objective has to be set – a one-sentence description of the overall outcome of the sprint.
The second part of sprint planning requires a more detailed discussion of how the selected product backlog items will be delivered. This might include some identifying tasks for the product backlog items and estimating these in hours or story points. The details should be documented as a plan in the Sprint Backlog. Besides, it has to be defined, whether there are any dependencies between the product backlog items.
Detailed planning is meant to help the team to separate the stories into tasks, as this will allow the team to consider everything that should be done to finish the stories.
The second part of sprint planning requires estimation of the stories – scrum teams can do this using strategies like "planning poker" or "t-shirt sizing" and allow team members to sign up for the work they choose. The team members give an estimate as to how long each task will take to complete or how complex the task is, measured in virtual points
The successful sprint planning event should lead to three goals:
Agreed and committed sprint goal;
A sprint backlog with all the tasks that will be completed during the sprint;
Enough detail and shared understanding to start the work.
The sprint goal is the topic that can provoke discussions – it is the result of a negotiation between the product owner and the development team. A good sprint goal has to be specific and measurable enough to guide the development team on why it is building the increment (the sum of all the product backlog items completed during a sprint).
Part two:
How?
If all three are reached, a safe and trustful environment within the team is preserved, the sprint planning meeting has been conducted successfully enough to move to the development part.
Common pitfalls
Sprint planning might turn out ineffective for some reasons:
A product owner does not have a sprint goal in mind;
A product backlog isn't refined/groomed enough;
Unknown velocity and upcoming capacity of the development team;
The "definition of done" is not considered when crafting the sprint plan;
Completed sprint planning event without a shared commitment to the upcoming sprint plan and goal.
One of the most common problems is a product backlog that is not refined/groomed enough. This can be prevented by adding precise results to the user story so that the outcome can be measured. It is recommended to add as much clarity as possible so that everyone gets the needed transparency.
To avoid the possible obstacles to successful sprint planning, it is recommended to ask a lot of questions during the meeting. Leaving things vague is much worse than leaving some questions to be answered while running a sprint when it's usually too late.
Another issue that often arises is a sprint goal, which is not specific enough. This may lead to a set of unrelated items that the team has to work on. As a result, a lot of work can be done without a feeling of progress.
One more common mistake is to plan way too many stories and drown the team with an unnecessary feeling of failure – focus on the goal and build enough of a sprint backlog to get started. Keep in mind that it's a sprint, not a marathon.
Remember, that Scrum is a complex framework, aiming at resolving complex problems. It uses an empirical process to solve these problems, the main principle of which is "learning by doing." Empirical processes, in their turn, are arduous to plan. So instead of trying to build a detailed step-by-step plan, it is rather recommended to focus on the outcomes and get going.
If your team is following Scrum framework, and you need to organize your workflow –
try our Sprint planning template.
It is a clear and simple example of the sprint planning process. You can use this example as a basis for your project – don't start from scratch.
How to use this template?
Create a new project and choose the Sprint planning template to start. All Infolio templates include some demo content. Feel free to remove it once you've familiarized yourself with
the concept.
The tasks are grouped in "Backlog", "Prioritized", and in sprints: "Sprint 1", "Sprint 2", "Sprint 3" etc., so you see all your completed and ongoing sprints at a glance. Example tasks provide general guidance – feel free to remove them, and add your own tasks and lists with just a few clicks.
Group tasks by Status to track their progress (e.g. "In progress", "Waiting for review", "Done") . In this view you can easily add new statuses to your workflow or rearrange existing ones. Update the status of any task by dragging and dropping it to the corresponding column.
To see how tasks are distributed within your team, group the project by Assignee. In this view, you can reassign tasks quickly by dragging and dropping them between columns.
If you need any further help or if you have suggestions about how to improve
this template, don't hesitate to let us know!
