A Sprint Planning Meeting Agenda that Drives Results (+Free Template)

"Successful use of scrum depends on people becoming more proficient in living five values: commitment, focus, openness, respect, and courage."

The Scrum Guide

If you’re searching for a sprint planning meeting agenda to run your first meeting or want to improve your current meeting structure, you already know how valuable scrum is.

Consider the above quote a “congratulations” on choosing one of the best ways to accelerate software delivery, which thrives on unparalleled values. 

Defined meetings are one of the powerful pillars of the scrum. They include sprint planning meetings, daily standup meetings, sprint review meetings, and sprint retrospective meetings.

A sprint planning meeting is when a scrum team (consisting of the scrum master, the product manager, and the developers) meet to plan for the next sprint.

In this article, we'll zoom in on the definition of such meetings, who attends them, their purpose, how to prepare for them, and what to include in the agenda.

What is a sprint planning meeting in agile?

A sprint planning meeting is a meeting where a scrum team meets to plan the next sprint. 

According to the scrum guide, sprints are the heartbeat of scrum, where ideas are turned into values. They are fixed-length events of one month or less to create consistency. A new sprint starts immediately after the conclusion of the previous sprint.

In other words, it's the time during which a certain product goal is achieved.

The most important outcome of the sprint planning meeting is that the meeting attendees (scrum team) can describe the sprint goal and know how they will work towards that goal. So, who does the meeting include to reach that outcome?

When is a sprint planning meeting held?

A sprint planning meeting is typically held every two weeks. However, according to each team's needs, it can be held every one to four weeks.

Sprint planning meetings are called time-boxed meetings, meaning that you should set a time limit for each meeting. If a sprint takes a week to be executed, the sprint planning meeting should not take more than two hours. And to plan for a two-week sprint, the meeting should not last more than four hours, and so on.

The scrum master is responsible for communicating the timeboxing concept with the team. It's important to know that while a timebox is the maximum time allowed, there is no minimum time. So, if the team finishes all the required agenda items during the designated time, then the meeting concludes.

How to prepare for a sprint planning meeting

The preparation of the sprint planning meeting falls mostly on the shoulder of the product owner. It's her/his responsibility to organize the meeting minutes from previous sprint review meetings and added info from stakeholders and go over the vision for the product, so they set the tone for the meeting. 

1. Preparing the product backlog items

The backlog items are the product features. So, a sprint backlog is a list of all the tasks (features) you need to accomplish to have the final product or, in other words, complete the project.

Preparing the product backlog items is not an easy task and takes a significant amount of time. However, it's worth it because good preparation guarantees a successful sprint planning.

If done right, the product owner will have a complete understanding of the details of each feature, so that she/he can answer any questions. Noteworthy is that the product owner doesn't have to explain the whole product backlog; a good guideline is being prepared to talk about product backlog items that cover the next two sprints.

An essential part of planning for the next sprint includes reviewing previous sprints. Items that were not completed in previous sprints might be moved to the backlog. The backlog also includes new items that surfaced during previous sprints. The scrum team will review the backlog to check out what’s remaining to work on and decide on what should be done next to keep the project on track.

Many agile teams use a burnout chart, a graphical illustration of the work remaining in a project and time needed to finish it. This helps keep teams on track, give team members a sense of achievement, and enhance collaboration.

2. Creating user stories

Atlassian defines the user story as the smallest unit of work in an agile framework and highlights the fact that it’s an end goal, not a feature, expressed from the software user’s perspective. The product owner and product manager (program manager) collaborate to write the user story.

In a sprint planning meeting, the developers can take a high-level user story of the product backlog items and turn them into more detailed tasks. The team decides what stories they’ll tackle and discuss the requirements and functionality that each user story needs.

Another outcome of discussing user stories in the meeting is scoring the stories based on their complexity or time to complete. To make proper estimations, teams use t-shirt sizes, the Fibonacci sequence, or planning poker. A story should fit in one sprint to be completed. So, when the team checks stories, they need to break them up so that a story fits in one sprint to complete.

3. Forecasting team's progress

Here's what the scrum guide has to say about forecasting the team's performance: "Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While
proving useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making."

Apparently, forecasts are based on available knowledge. To have good estimates, an environment promoting trust and freely sharing information should be encouraged. Estimates are determined for the sake of learning and improvement. It's best if they are not used in a negative, confrontational way.

Most agile teams use burndown charts and story points to forecast their performance. You should also consider the following when forecasting the performance.

Team's capacity 

The team's capacity or availability can be forecasted based on two things: (1) asking team members to confirm any time off, commitments to other projects, and possible time restraints and (2) ensuring the availability of all the necessary resources. Also, important to consider are any known issues or setbacks, and they should be factored into forecasting the capacity as well.

So, to predict the team's capacity, you start by knowing the number of team members and multiply that by the number of working hours for two weeks; for example, if you decided on a sprint that lasts for two weeks. Then, you start subtracting unavailability hours within these two weeks, which include meeting hours, members taking time off, and hours committed to other projects.

Estimating velocity

You need to determine the pace at which the team is working (velocity) to have good estimates of the performance. To determine the team’s velocity, the scrum master or product manager will look at previous sprints or previous projects to obtain insight into how quickly the team usually finishes similar tasks. It's best if you never use the same velocity for different teams because it's unique to every team.

💡Note: If the team is new and doesn’t have an established velocity, it's best if the product owner doesn't suggest a sprint forecast. Instead, the first sprint should be an exercise for the whole time. Forecasting the pace at which the team works is a trial-and-error process. In this process, at the first sprint, the team will use its best judgment regarding predicting velocity, and after a few sprints, good estimates will be obtained.

What is the purpose of a sprint planning meeting?

The purpose of a sprint planning meeting is to define a goal for the upcoming sprint and determine who will do what to achieve that goal. For that to happen, you need key inputs to build your meeting as follows:

1. A focus area: Using previous sprint planning meetings and sprint reviews and reminding the team of the broader product goals, the product owner proposes a focus area. This will help inform the team to collectively define a sprint goal during the meeting.

2. The backlog: After the sprint goal is defined, the team should review the product backlog and choose relevant items to be included in that sprint. The backlog should be up to date and includes items that the team was unable to cover in previous sprints.

3. Forecast of team’s capacity and velocity: To know if you've chosen the right workload, it's important to monitor the team's capacity and velocity in previous sprints and record how many story points are burnt down in a sprint.

Examples of sprint goal, user stories backlog, and sprint tasks

Check out this practical example from one of adam.ai's sprints. The following shows what a sprint planning meeting output should look like. Read the next section to explore how our sprint planning meeting agenda can help you write an excellent sprint goal and help the developers break down the user stories backlog into sprint tasks.

Sprint goal:

• Build the system base and provide users the way to register and login into the system by passwords and third parties.

User stories backlog:

• I can sign up via my email and password
• I can confirm my email to enter the system
• I can log in via my email and password
• I can signup/in via my Facebook account and directly log into the system

Sprint tasks:

• Design and create users' database
  

What to include in a sprint planning meeting agenda

Your sprint planning meeting agenda should help the scrum team answer the following: why are we doing this sprint? What can be done during this sprint? How will the work be done?

1. Introduction

Reminding the team of the big picture

Reminding the team that they’re all working hard towards the same goal is crucial. While a sprint planning meeting is a recurring meeting and you may feel there is no need to mention the broader goals at the beginning of each meeting, repetition increases awareness and learning for everyone involved.

Start the meeting by mentioning the project’s vision and goals. Acknowledge the team’s work in the previous sprint. Encourage the team and offer a positive and enthusiastic outlook on what’s to come.

Communicating any new information and updates

There is a high chance that since the last time the team planned a sprint, any of the team members may have received updates from outside stakeholders. It's important to go over any new information from the market or customers that helps to set the context for the upcoming sprint.

Highlighting general issues

Roadblocks such as a lack of resources, poor communication, and others should be highlighted. You can discuss them in this meeting, but make sure that the meeting remains within the designated timebox. Or record them to refer to them later in a separate meeting.

2. Reviewing the last sprint*

To start the current sprint, you need to go over what happened in the previous sprint. You can first start by acknowledging the team’s work. Then, confirm with the team any issues that are specific to the last sprint and record them. Review the story points and record what was done and what needs to move to the backlog again or be considered for the next sprint. Ask the team for their feedback on what needs to be changed in the next sprint.

*Skip this item if that’s your first sprint.

3. Discussing the current sprint

This is where the product owner presents the proposed backlog. It should cover the size of two sprints, so the product owner can efficiently answer the team’s questions. It’s noteworthy that, while the product owner prioritizes the backlog and communicates requirements from the stakeholders, the developers are the ones who decide how the sprint will go because they know the technicalities and the level of effort needed to finish the backlog items.

So, what does a sprint planning look like? Here are the agenda subitems.

A. Work on identifying sprint goal: what do we want to achieve this sprint?

The team decides on what they need to accomplish in this sprint. To define a solid sprint goal, make sure to include previous sprints’ goals, guidelines, and any other resource your team will need to define an efficient sprint goal.

B. Select user stories from the product backlog

The most important thing the team needs to consider when selecting user stories is that their goal is not to go faster but to deliver value. The team decides on user stories according to priority and their capacity and velocity.

C. Revisit the definition of done (DOD)

DOD is the list of items that determine a user story is done. It is applicable to all items in the backlog. You need to revisit to refresh memories and update new members. DOD can serve as a checklist to come up with the tasks for the user story.

D. Decide on sprint backlog and break down user stories into tasks

This is the bulk of the meeting where the team members collaborate to come up with a sprint backlog, break down user stories into tasks, and confirm who owns certain tasks.

Here are a few things to consider when breaking down user stories into tasks: (1) Keep the tasks the right size. Avoid breaking the stories into very minute tasks. You need the task small but not too small. Break the stories into tasks that take around 8 hours to complete not just a few minutes.

(2) Create tasks with a precise description. It’s best if you avoid descriptions like "coding" or "implementation" and depend on people referring to the user story for details. Write meaningful descriptions with a clear scope.

(3) It’s best if developers use both the user story’s acceptance criteria and DOD to come up with a task. While DOD is a list of requirements for all backlog items to be complete, the acceptance criteria are a set of test scenarios specific to each user story that must be met to confirm that the software is working as expected. Here is an excellent example of what acceptance criteria look like according to Visual Paradigm:

Discuss the velocity for this release

To discuss the proposed velocity for this sprint, the story points and the team’s velocity in previous sprints should be considered. The team should align on how many story points will be done this sprint. It’s best if this is stated clearly to the whole team to avoid unrealistic assumptions.

Confirm the team's capacity

Forecasting the team’s capacity is an important part of a successful sprint. You should consider public holidays and other ongoing projects and ask the team members to inform you about their time off.

Consensus on the plan

After identifying the sprint backlog and sprint plan, the scrum master needs to make sure that everyone is comfortable with that plan. The aim of group consensus is to verify if the team is aligned on the plan and the proposed velocity and capacity and that the plan agrees with the product’s vision.

The new sprint has just started

Now that everything is in place, it's time for the new sprint to start. Remember that, after the sprint planning meeting, there are several meetings to follow, like daily standups and sprint review meetings. These meetings are designed to synergistically help you reach the product’s vision.

Sprint planning meeting agenda template

Because sprint planning meetings are recurring meetings, you can start by using an agenda template and adjust it to fit your team's needs. 

Explore our sprint planning meeting agenda template from adam.ai's template gallery. It'll help you start your sprint planning meeting on an excellent note.

More meeting agenda templates

You can also find a list of other useful meeting agenda templates on our blog, which can guide you to hold effective meetings:

1. Team meeting agenda template

2. Board team meeting agenda template

3. Quarterly planning meeting agenda template

4. Standup meeting agenda template

5. Status meeting agenda template

6. First meeting with new team agenda template

7. Brainstorming meeting agenda template

8. Skip-level meeting agenda template

9. Kick off meeting agenda template

10. Sales team meeting agenda template

11. Retrospective meeting agenda template

How to effectively execute your sprint planning meeting agenda

Agile frameworks like scrum require agile software to support them. Combining the two will lead to outstanding outcomes. An all-in-one meeting management software, like adam.ai, is second-to-none when it comes to processing and organizing all the info that sprint planning meetings entail and helping you keep your sprint planning meetings time-boxed.

So, have your sprint planning meeting agenda prepared, and let's explore how adam.ai can help you execute and organize all your sprint planning meetings effectively.

1. Work on several projects simultaneously with ease. Create projects with every detail recorded: insights, follow-ups, timeline, actions, decisions, risks, and issues.

A screenshot from adam.ai: Meeting spaces 

2. Create a series of sprint planning meetings to be repeated every two weeks for as long as the project takes, and use your favorite video conferencing tool. 

Screenshot from adam.ai: Creating a series of meetings

3. Go through a timeline that records every action and detail about your meetings.

Screenshot from adam.ai: Insights

4. Link relevant meetings and upload important files.

Screenshot from adam.ai: Attachments

5. Add your timed agenda items. 

Screenshot from adam.ai: Agenda

6. Create, schedule, assign, and send your action items to your integrated apps, like Asana, Trello, and Jira. Check out other integrations adam.ai has.

Screenshot from adam.ai: Assigning and scheduling action items

7. Take notes in real-time and style them according to your needs.

Screenshot from adam.ai: Taking notes

8. Use Adam the AI meeting assistant to suggest and enhance content.

Screenshot from adam.ai: Using Adam the AI assistant to enhance writing

9. Add decisions and vote on them. Tag people you want to vote on decisions and add any comments or files related to these decisions.

Screenshot from adam.ai: Creating polls

10. Have meeting discussions with the attendees and collaborate on them

     Screenshot from adam.ai: Meeting chat

11. Have your meeting summary generated in a matter of seconds using Adam the AI assistant.

Screenshot from adam.ai: Automatically generated meeting summary

All the above features will help you create a smooth-sailing scrum meetings' workflow, especially if you've just started applying the scrum framework. Using adam.ai, you can effortlessly overcome two of the biggest challenges in conducting meetings: (1) processing a huge amount of info and (2) keeping your meetings within the designated timeframe.

You can reach new levels of mastering sprint planning meetings today by giving adam.ai a try. Just click on the button below, and you'll have access to all the above features (all features are unlocked for a seamless experience).

The bottom line

To sum up, in this article, we've touched on the definition of sprint planning meetings, who attends them, when they should be held, their purpose, and how to prepare for them. You've also gone through a detailed meeting agenda, with every item explained, and got to know what the meeting's output will look like.

Important to remember is how agile meeting management software goes hand in hand with agile frameworks. In this article, you had a preview of how all-in-one meeting management software, like adam.ai, can help you excel at your sprint planning meetings, process a huge amount of info, and significantly reduce time.

And while there may be multiple meeting management solutions available, here is why adam.ai is the all-in-one meeting management platform you can trust:

• adam.ai is one of Atlassian Ventures' portfolio companies.
• In the meeting management software category on G2, adam.ai has been ranked a leader and a high performer for successive quarters in the past years.
• adam.ai has been included in the Forrester Report in the AI-enabled meeting technology landscape.
• adam.ai is trusted and used by powerful teams and organizations worldwide for all types of critical meetings, like board, committee, project management, and business development meetings.
• And most importantly, adam.ai integrates with your existing workflow, is SOC2 compliant, provides dedicated support and success, and has a free trial option.