"Successful use of scrum depends on people becoming more proficient in living five values: commitment, focus, openness, respect, and courage."
What makes scrum a unique framework is that everyone in scrum is responsible for the success of the project. It is one of the most agile and used frameworks, especially in SaaS (Software as a Service).
In this article, we'll zoom in on sprint planning meeting and learn more about its definition, who attends it, its purpose, and how to prepare for it. The article also includes a free sprint planning meeting agenda template and a detailed explanation of each agenda item.
Here's a list of what this article tackles:
What is a sprint planning meeting in agile?
As the name implies, it is a meeting to plan a sprint. So, what exactly is a sprint in scrum framework?
According to the scrum guide, sprints are the heartbeat of scrum, where ideas are turned into value. 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?
Who attends a sprint planning meeting?
To answer the previously asked question, you have to know who is supposed to attend this meeting and what their responsibilities are. The scrum team attends the sprint planning meeting, and it consists of the product owner, scrum master, and developers. Each has their responsibility. The following definitions and responsibilities are quoted from The Scrum Guide.
|Product owner||Scrum master||Developers|
|Role||The product owner is one person, not a committee. They maximize the value of the product resulting from the work of
the scrum team. They identify the product mission, the product roadmap, and a release plan with the highest-priority features launching first.
|The scrum master is accountable for establishing scrum as defined in the Scrum Guide. They do this by
helping everyone understand scrum theory and practice, both within the scrum team and the
|They are the people in the scrum team that are committed to creating any aspect of a usable increment each sprint.|
Developing and explicitly communicating the product goal.
Creating and clearly communicating product backlog items.
Ordering product backlog items.
Ensuring that the product backlog is transparent, visible and understood.
Coaching the team members in self-management and cross-functionality.
Helping the scrum team focus on creating high-value increments that meet the definition of
Causing the removal of impediments to the scrum team’s progress.
Ensuring that all Scrum events take place and are positive, productive, and kept within the
Creating a plan for the sprint, the sprint backlog.
Instilling quality by adhering to a definition of done.
Adapting their plan each day toward the sprint goal.
Holding each other accountable as professionals.
|Authorities||Has the authority to cancel the sprint||Runs the sprint planning meeting||Decides which tasks to include in the sprint|
When is a sprint planning meeting held?
After establishing the definition of sprint planning meeting and knowing who attends, it's important to know the time intervals at which the sprint planning meeting is held and how long the meeting is.
Setting a time limit for sprint planning meetings is essential. That's why they're called time-boxed meetings. For each week of executing a sprint, the sprint planning meeting should not take more than two hours. So, for example, to plan for a two-week sprint, the sprint planning meeting should not last more than four hours.
To make sure the timeboxing is applied, the scrum master is responsible for communicating the timebox concept. 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
Before sending out sprint planning meeting email invites, you need to make sure the sprint planning meeting is well-prepared.
The preparation of the sprint planning meeting falls mostly on the shoulder of the product owner. It's their responsibility to organize info from the previous sprint review meetings, stakeholders, and vision for the product, so they set the tone for the meeting. So, the first thing to do when preparing for sprint planning meeting is –you've guessed it– preparing the backlog items.
1. Preparing product backlog items
As explained before, 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.
This 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 they answer any questions that the team may have. 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 important 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.
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
proven 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 the 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.
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.
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 on 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 with regard to predicting velocity, and after a few sprints, good estimates will be obtained.
What is the purpose of sprint planning meeting?
You now know what you need to prepare for the meeting, and it's time to write the agenda. Before getting into the agenda, let's organize our thoughts. To craft a relevant and solid agenda, you need to be clear on the purpose of the meeting and what key inputs you’ll introduce.
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 the meeting on 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 on 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.
- Build the system base and provide users the way to register and login into the system by passwords and third parties.
User stories backlog:
- As a user I can sign up via my email and password
- As a user I can confirm my email to enter the system
- As a user I can log in via my email and password
- As a user I can signup/in via my Facebook account and directly log into the system
- Design and create users' database
- Implement user creation logic
- Implement confirmation email flow
- Expose signup API
- Expose confirm email API
- Design signup page
- Design confirmation email template
- Integrate with signup API from signup page
What to include in a sprint planning meeting agenda
So, let’s break down the agenda. Your agenda should help the team know the answer to the why, what, and how: why are we doing this sprint? What can be done during this sprint? How will the work be done?
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 help 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 refine it until you reach the agenda that's best working for you.
Explore our sprint planning meeting agenda template. It'll help you kick off your sprint planning meetings.
More meeting agenda templates
You can also find a list of other useful meetings agenda templates on our blog, which can guide you to hold effective meetings:
How to run sprint planning meeting effectively
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, let's take a look on how adam.ai can help you execute and organize 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: Creating a project
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: Project meetings' timeline
4. Link relevant meetings and upload important files.
Screenshot from adam.ai: Linked meetings
Screenshot from adam.ai: Uploaded files
5. Add your timed agenda items and sub-items.
Screenshot from adam.ai: Creating timed agenda items and sub-items
Screenshot from adam.ai: Assigning and scheduling action items
Screenshot from adam.ai: Sending tasks to integrated apps
7. Take notes in real-time and turn them into agenda items, actions, or decisions.
Screenshot from adam.ai: Taking notes in real-time
8. Record the risks and issues.
Screenshot from adam.ai: Issues
Screenshot from adam.ai: Risks and issues
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.
10. Have meeting discussions with the attendees and turn your discussions into actions, decisions, or agenda items or add them to notes.
Screenshot from adam.ai: Meeting discussions and turning them into actionable items
11. Have your meeting minutes automatically generated in a matter of seconds with a click of a button.
Screenshot from adam.ai: Automatically generated minutes
All the above features will help you create a smooth-sailing scrum meetings' workflow, especially if you've just started out 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 below button, and you'll have access to all of the above features (all features are unlocked for a seamless experience).
14-day pro. No credit card. No hidden fees.
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 went 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.