Sprint planning is a meeting held before each sprint to define the goal of the sprint and decide how to accomplish the goal. This guide will walk you through the ins and outs of sprint planning and help you take control of sprint planning meetings for the whole team.
In this guide:
What is sprint planning?
With sprint planning, every project is broken into time blocks, or sprints, usually two to four weeks long (though some teams prefer shorter sprints). Sprint planning provides each team member with actionable tasks and deadlines for work items to be completed before the end of the sprint.
A sprint planning meeting is when the team (including the scrum master, scrum product manager, and scrum team) meets to determine which backlog items will be handled in the next sprint.
The process is collaborative, affording everyone a say in what tasks and projects represent a priority for the team — and how long each will take. By the end of the meeting, everyone should know exactly what’s expected of them for the duration of the sprint and have a shared consensus on the goal of the sprint and have that goal in writing.
Sprint planning is a collaborative process that allows team members to have a say in when work happens.
Who does sprint planning?
- Product owner — This person leads the preparation for sprint planning, including refining and prioritizing the backlog. During sprint planning they guide by defining the sprint goal — why the team is having the sprint — and finalizing the sprint backlog, or the plan for the sprint.
- Scrum master — This role schedules and facilitates the sprint planning meeting. During sprint planning they assign tasks to team members and ensure no one is overcommitting, monitor the sprint backlog as it forms, and summarize the sprint planning meeting.
- Scrum team — These people are the rest of the participants of the sprint planning meeting. They’re the ones executing the goal. During the meeting, their tasks are to understand the sprint goal, help refine the backlog and estimate user stories (the smallest unit of work in an Agile framework), determine their individual capacity, and commit to their user stories and tasks.
Why is sprint planning important?
Sprint planning is a productive way of working because it involves all members of a team. Instead of working in isolated silos, team members are engaged in the rollout of a project or campaign, know their tasks and responsibilities within it, and can react to changing elements.
Benefits of sprint planning.
- Define a clear sprint goal as a team. If you are in a room with a whiteboard or equivalent, write the primary goal where everyone can see and refer to it.
- Start the sprint with an agreed-upon plan. Roles and responsibilities are constantly clarified, as are project scope and goals — ensuring the most effective use of everyone’s time.
- Establish realistic expectations. Whenever possible, assign deadlines with a little extra padding in case of setbacks.
- Identify any possible roadblocks. Sprint planning is an iterative and nimble process that allows for flexibility should a setback occur.
Managing the work involved into sprints can help with focus and productivity. Building a shared understanding over workflows can really improve teamwork.
Sprint planning meeting agenda.
Like any meeting, your sprint planning meeting will need an agenda to keep the team focused. Every sprint planning meeting agenda should include discussions about the ultimate objective of the sprint and the team’s capacity, followed by a granular look at the sprint backlog, before you start slotting tasks into the sprint.
Preparing for the sprint planning meeting.
Proper preparation saves time during the sprint planning meeting and reduces the chances of failure. Before starting this meeting, the product owner is responsible for preparing and motivating the rest of the team to prepare.
How to prepare for a sprint planning meeting:
-
Refine the product backlog. The product backlog is a prioritized list of all possible tasks needed to deliver a product. A sprint backlog is a list of items taken from the product backlog to be addressed in the next sprint. Refining the product backlog means actively managing it by adding new items as ideas or requests come in, while also removing or modifying items as needed.
Since you’ll be pulling tasks from the product backlog to include in the next sprint, refining the product backlog will save time and frustration. Asking everyone on the development team, as well as the scrum master, to help refine the product backlog will save time during the meeting and make it easier to find appropriate tasks for the next sprint.
-
Review the last sprint. Reviewing the last sprint — or the last sprint retrospective — will help you see what tasks are left over from the previous sprint and will also help you gauge how long the next sprint should be.
-
Review the overall project. Take a step back to remember what value you’re trying to bring to your customers. Use this time to ask stakeholders for feedback and additional context. Don’t forget to consider the current market.
Sprint backlog.
Your sprint backlog is a list of all the tasks you need to accomplish during a sprint. During the sprint planning meeting, your team will review this backlog to look at what’s left to work on and decide what should happen next to keep the project on track.
Any items not completed in previous sprints might be moved to the sprint backlog. New items that might have popped up during previous sprints will also be here.
Estimating stories.
Once you have your backlog of items to work on, it’s important to estimate the time or effort it will take to complete each item. This information helps the scrum master or scrum product manager to manage the budget and timeline of the project more effectively.
To fairly capture this data, the scrum team will discuss and collaboratively estimate the size of each task — often called user stories. This is done using numerical points, hours, comparative sizes (such as XS, S, M, L, XL, and XXL), or another means of capturing the effort required.
It’s important to take into account each team member’s effort rating. This is especially useful if it’s substantially higher or lower than the rest of the group, in case that person has insights about the task’s complexity or simplicity the rest of the team hasn’t considered. These discussions can help get to more effective time estimates.
Once items are estimated, you’ll be able to determine how many of these user stories, and in which combinations, will fit into your upcoming sprint, based on your team’s available capacity.
Determining capacity.
Your team’s capacity is a measurement of how many story points or backlog items they can complete during a sprint under normal circumstances. To find your team’s capacity:
- Multiply the number of team members by the number of hours they can productively work in a day
- Subtract time spent in team meetings or devoted to other tasks or projects
Let’s look at a simplified example:
- If you have a team of seven people working eight productive hours a day, you calculate their capacity by multiplying seven team members by eight hours. This gives you 56 points per day — or 280 points per five-day workweek.
- Then, subtract unavailable time, such as meetings, time off, and other distractions. So, if you have a two-hour team meeting every Wednesday, subtract 14 hours from the total (seven workers x two hours). If two team members take two days off each, subtract 32 hours from the total (two workers x eight hours x two days). That would leave you with 234 total points.
- Also, you can’t assume every individual works at 100% capacity every hour of the day. Interpersonal conversations and coffee breaks are part of office life, so you may want to factor in each person’s fractional availability. If you assume each person-hour is 75% productive, multiply your 234 points by .75, and you end up with 175.5 total capacity points per workweek. If you work in two-week sprints, double that total to 351.
Determining velocity.
Next, you’ll want to look at the team’s velocity and capacity together. When determining the team’s velocity, the Scrum Master or Scrum Product Manager should be ready to use examples from the past few sprints or previous projects to indicate how quickly the team usually finishes similar work.
How to structure a sprint planning meeting.
A well-structured sprint planning meeting sets your sprint planning up for success. You know you’ve effectively organized your meeting before, during, and after when all team members have a shared understanding of the tasks, helping them to collaborate throughout the sprint.
- Identify the goal. A sprint goal is a statement of one to two sentences describing the overall purpose of the sprint. The product owner should bring a general goal to the sprint planning meeting and facilitate by asking open-ended questions.
- Discuss any updates. The team should discuss what’s happened since the last sprint retrospective that may impact this sprint. Thoroughness and transparency are key for this step.
- Determine the sprint’s velocity. You’ll want to figure out how long the sprint should take — also called the sprint velocity — or the time frame necessary to accomplish the tasks. The best way to determine velocity is to look at how long past sprints took. Typically, most sprints are one to two weeks.
- Discuss the team’s capacity. Everyone on the team has the chance to say what they’re capable of doing this sprint based on their availability and workload.
- Choose sprint backlog items. First, review the product backlog. Then, estimate user stories to make sure they are manageable. If they are too big, split them into smaller user stories. Tasks should be worth doing and achievable within the short sprint time frame. Once you’ve decided on items to work on, move the items from the product backlog into the sprint backlog.
- Assign tasks to team members. Once you have your items, everyone on the team should decide what they can do for this sprint. The scrum master can record what everyone is committing to.
- Record concerns and dependencies. After tasks are assigned, the team should evaluate dependencies — meaning a potential setback such as another department not providing feedback on schedule. The team should also consider concerns — such as overall time management.
- Reach consensus. The group should end with collectively agreeing they will carry these two artifacts into the sprint: the sprint goal and backlog.
How long should a sprint planning meeting be?
The length of a sprint planning meeting can vary depending on the size of the development team, complexity of the project, and the duration of the sprint. A good rule of thumb is the number of hours needed for sprint planning is two times the number of weeks in the sprint. However, as time goes on, you might find that shorter meetings work better for you.
This equation will leave plenty of room for thorough discussion, allowing time for each team member’s voice to be heard and for everyone to understand the sprint’s goal and the work that needs to be done. On the other hand, if your sprint planning session goes on for too long, your team can potentially lose focus, straying into conversations that don’t require everyone’s attention or trying to address more than the next sprint alone.
Best practices for sprint planning.
Minimize your own team’s learning curve by using the following tried-and-true strategies to ensure a collaborative, positive experience for all involved:
- Start with a refined backlog. This helps teams begin with a comprehensive understanding of the stories and ensures they’re working on the most important tasks possible.
- Define clear goals. Only move on from a user story after clearly defining its goal.
- Utilize daily scrums. Scrum masters will typically hold morning meetings, known as scrums, that should last no more than 15 minutes. The aim of a scrum is to quickly run through each person’s daily workload and identify any potential complications ahead of time.
- Plan just enough. Avoid dictating expectations. Rather, listen to and consider what teammates believe they are capable of in the coming weeks.
- Decide what done means. There’s a fine line between empowering team members with the necessary details and micromanaging. Whenever possible, define a clear endpoint during sprint planning.
Getting started with sprint planning.
Sprint planning helps teams efficiently accomplish projects using their individual resources — their time and skills. When you’re ready to get started, review your backlog and choose what tasks are worth pursuing and achievable within a short period of time.
Help ensure the best possible results with tools designed to help facilitate a frictionless, agile sprint planning experience.
With Adobe Workfront, the combination of resource management and configurable dashboards — as well as native integrations — empowers your team to respond quickly to shifting priorities and deadlines. Workfront was founded to help people, teams, and companies get work done. Today, more than 3,000 organizations and the world’s top 10 brands use it daily.
