Sprint planning is one of the central aspects of the Agile Scrum framework. The sprint planning meeting takes place before the start of a new sprint to determine the sprint plan and set a sprint goal.
Sprint meetings are designed to answer any and every question that team members have on their minds.
This blog post will outline everything you need to know about how to handle sprint planning meetings like a pro to avoid wasting time and resources.

What Is A Sprint Planning Meeting?

Sprint meetings are the foundation of the Scrum methodology. In Scrum, all work is limited to regular work cycles, called sprints. A sprint is usually two weeks long, but they can be as short as 1 week or as long as 4 weeks. The length of the sprints depends on what the team considers to be most efficient for them.
Because the sprint time period is so short, the team is forced to focus on the most important function or characteristic of tasks first. The Scrum methodology works in increments, meaning that as soon as one sprint ends, there is a sprint review meeting and the next sprint begins.
Every sprint begins with a sprint planning meeting where the product owner and the rest of the team come together to decide which tasks should be moved from the product backlog to the sprint backlog.
At the sprint planning meeting, the product owner decides what the team should work on and the team decides how to complete the work.
As mentioned above, at the end of each sprint, there will be a sprint review meeting, when the team presents potential deliverable product increments to product owners, stakeholders, and users, if they are interested.

How to Plan a Sprint in Agile

Running a great sprint planning meeting is no easy feat but it can be done with proper planning. Product owners need to be prepared, combining the lessons learned from previous sprint reviews, feedback from stakeholders, and their vision for the product so that they can prepare for the sprint. Additionally, the product backlog should be up to date to provide clarity and transparency. Most teams prefer to get together to review the backlog prior to the sprint planning meeting.
Here are some of the best practices to implement in your next spring planning meeting:

Set Time Limits for Sprint Planning

Sprint planning should be limited to no more than 2 hours for each week of the sprint. This is called “timeboxing”, which simply means setting a maximum amount of time for the team to accomplish a task. It is the responsibility of the scrum master to make sure that the timebox is understood by all members of the team. If the team is content before the timebox finishes, then the event is over. Bear in mind that there is no minimum time for a timebox, only a maximum time is set.

Estimate Sprint Velocity

Before every sprint, the product owner will estimate the velocity – the amount of work that will need to be done during the sprint. This will vary from team to team based on their schedules and capacity.
The purpose of estimating velocity is to develop a new velocity for every sprint. Looking back at past sprints will help reflect on objectives, outcomes and effectiveness, and set realistic expectations for the upcoming sprint.

Review Your Product Roadmap

The first step to sprint planning is to know what you want to achieve – in the next 6 months, in a year and so on.
It is the responsibility of the product owner to look back on the product roadmap and evaluate the team’s goals and outcomes. Focus on the long term goals before breaking down your plan into sprints. Sprints are not about crossing things off a checklist, they’re about bringing you and your team closer to the end goal.

Update Product Backlog

A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The product owner is responsible for the content, availability, and priority of the product backlog.
It is a living document, constantly getting edited and improved. It lists all the features, use cases, user stories, improvements, and bug fixes that are being made to future releases. This document exists only as long as the product exists.

Set Your Sprint Goals

A sprint goal should help the team understand the purpose and impact of the work they are doing. Setting sprint goals helps team members collaborate with one another, stay focused on the long term goals and helps with prioritization of tasks during the sprint. The creation of the sprint goal is usually guided by the product owner.
Ideally, you would have one sprint goal per sprint, ensuring that everyone is on the same page and working towards the same outcome.
The last step is for the stakeholders to evaluate the sprint goal and provide their feedback.

Allocation of Sprint Work

This is where the scrum master comes in. The scrum master works together with the team to meet the requirements set by the product owner. By working together on this, the scrum master and the team can allocate the work that needs to be done in the sprint to the right members of the team. The team is in charge of managing the sprint towards the end goal.
Assess people’s skills and assign tasks accordingly. This will help team members to feel motivated in what they’re doing and will encourage them to take responsibility for their work.

Sprint Planning Meeting Preparation + Agenda

In order to prepare for the sprint meeting, a proper agenda must be in place to ensure everyone stays on track. Here is everything you should include in your meeting agenda:
1) Sprint goal and roadmap – The Scrum Master starts the meeting by proposing sprint goals and placing them in the context of the product roadmap. They will explain where the team currently stands on the roadmap, what the next step is, and how the sprint goal supports them.
2) Technical and operational context – Members of the team get together to exchange information that is vital to the sprint meeting discussion such as what projects were recently completed, important technical lessons learned from recent work, and team capacity and capabilities.
3) Velocity – Velocity metrics capture the team’s ability to deliver value to customers in the form of completed and delivered user stories. The Scrum Master provides the team with a target velocity for the current sprint, which must be agreed on with the rest of the team. The target velocity is the basis of the sprint plan – the goal of the sprint plan is to select the best user story list that matches the target velocity to complete in the current sprint.
4) Team capacity – The meeting should establish the team’s capacity in the current sprint, calculated as the total number of work hours available for sprint work. This should take into account current team members, public holidays, vacations, and other factors that can affect available time.
5) Review the definition of done – The scrum master lists the mandatory and optional tasks included in the definition of done. In other words, what the team must do to consider each user story as done. The definition of done doesn’t usually vary from sprint to sprint and can be negotiated with the Scrum Master.
6) Deciding on product backlog items – The core decision of the sprint meeting is to prioritize what needs to get done during the current sprint. Sometimes backlog items that are too large will be split into several stories and a decision will be made on whether or not they’ll be included in the current sprint.
7) Deciding on quality and maintenance – This is something that is often overlooked. The Scrum Master must discuss current product quality, production defects, and customer complaints as well as other challenges, and set clear priorities for maintenance work in current and subsequent sprints.
8) Estimation of work – Based on the backlog items in question, the team will get a clearer picture of how much work is expected to be done and it will be allocated between team members. Taking into account the skills and experience of the team, and the potential uneven distribution of tasks, the Scrum Master can go back and adjust the to-do list.
9) Document external factors – Any important external factors that may affect the team’s success should be recorded as part of the sprint plan. This may include available technologies and tools, known technical issues, reliance on other departments, required special approvals, and others potential roadblocks.
10) Agreement to terms – The Scrum Master and Product Owner should take the sprint plan as the goal and maximize the agreement between all team members to achieve the strongest commitment to complete the sprint goal. If needed, the sprint plan can be adjusted. While consensus is the ultimate goal, it is inevitable that some team members may feel hesitant.
As for the creation of the actual agenda, we recommend Notiv of course! You can use Notiv Notetaker to record, transcribe and summarize your sprint meeting with highlights, action points and decisions made. After the meeting finishes, you can send the recording and transcript to your team members so they can refer back to it when needed. To find out more about how Notiv can help you meet better, click here.

How to conduct sprint planning meeting + template

We’ve covered what you need to do to conduct a sprint planning meeting so it’s time to have a look at a template to see what it will look like when the time comes for you to conduct your sprint meeting.
There are many templates out there online but we like this free one from Docket. Use it to review goals, define your scope and make decisions collaboratively.

Sprint review

The sprint review is a meeting between the development team, product owner, scrum master and stakeholders at the end of a sprint. The purpose is for the team to give a demo of what has been accomplished over the sprint and compare it to the commitment that was given at the beginning of the sprint.
For 4-week prints, the sprint review may take up to 4 hours. The general rule of thumb is that the duration of a sprint review per week should not exceed one hour.
The final result of the sprint review is a revised product backlog that outlines the product backlog items for the next sprint. The product backlog can be adjusted to make room for new plans and opportunities.

Conclusion

Sprint planning is all about clarifying and organizing work before getting down to it. Through a successful sprint planning meeting, you can more easily understand the goals, action plans, and results of the sprint. If the team doesn’t know where to go and how to get there, meeting customer needs will be difficult.
To find out more about which meeting management tools you need to be using in 2021, check out this blog post.