On your mark, get set, go! Olympic sprint races can be finished in 10 seconds or less, but you can bet world-class athletes have a clear race plan to set them up for success. Work sprints (thankfully!) last a little longer, but the planning sets the groundwork for successful execution.
Sprint planning should be used to improve project management and productivity. Sprint planning meetings help you keep track of what your team is working on while giving everyone a clear, action-oriented direction to work toward. To run a successful sprint planning meeting, you’ll need to understand the purpose of sprint planning and the steps involved in the process.
What is sprint planning?
Sprint planning is a process where a development team comes together to define the work to be done during the next sprint by reviewing and selecting the ideal number of relevant backlog items to work on. During this process, you and your team should discuss the technical and design aspects of upcoming sprint tasks, identifying potential challenges and dependencies.
How long is a sprint?
A sprint is a dedicated timebox, typically a two-week period in which teams have to complete a set amount of work. Under Agile methodology, projects are broken down into sprints, with each one getting you closer to completing the project.
While two-week sprints are a common and recommended practice, the duration of a sprint can vary based on several factors, including the team's preferences, the type of work, and the project's specific needs. Sprints can be as short as one week or extend up to four weeks or more.
The key is to select a sprint duration that aligns with the team's capacity and the requirements of the project.
Who should be involved in sprint planning?
The primary stakeholders involved in the sprint planning process include the product owner, scrum master (or project manager), and the development team.
If you work in Agile project management (APM), then you’ll know sprints are the main pieces of the Scrum framework pie. Scrum methodology helps teams solve complex problems with the following framework:
- A “Scrum master” or project manager facilitates the agile project from start to finish.
- The product owner enters the work and solutions to a problem into a product backlog.
- The Scrum or Agile team “turns a selection of the work into an increment of value during a sprint.”
- The Scrum team and stakeholders review the results of the sprint and make adjustments for the next one.
- The process repeats until all sprints are completed and the project is done.
How to run a sprint planning meeting
A sprint planning session should set you and your development team up for a successful and productive two-week sprint. In fact, adopting the Scrum framework can help increase productivity by more than 200% while also improving the quality of the work.
Product or software development teams that want to push new features typically use sprints to launch new products, or make other improvements to a product. During the planning meeting, you’ll cover three key factors:
- The objective of the sprint
- The product backlog items
- Team assignments
Before you begin your planning session, here are a few tips to set you up for success:
- Take a look at your product roadmap to get a high-level understanding of how this sprint fits into your overall strategy.
- If you don’t already know, decide who'll be the leader or Scrum master of this project.
- Confirm which stakeholders should attend the sprint planning meeting. For example, if you’re working on product development, you’ll want your product manager and development team there.
- Create a sprint planning meeting agenda so that everyone knows what to expect.
Then, work through the following steps in the meeting.
1. Review and categorize your sprint backlog
As you kick off your sprint planning meeting, conduct a quick check-in with your team. This is an optional step, but it helps you understand the mindset and feelings of the team prior to the planning session. Once you have an idea of your team’s sentiment, you can start reviewing the backlog.
As you review your backlog items, create a system to prioritize the different tasks. By going through this categorization process, you can narrow down which items it'd be best to work on during the upcoming sprint.
One option is to categorize them into a bucket system. The categories might include:
- Priority: Is it a high priority, a second priority, or a low priority?
- Relevance: Does it produce outcomes that support your newly defined goal?
- Status: Has this been worked on in a previous sprint? Is it near completion?
Start with the top-priority items first, which are most relevant to your goal and are feasible to work on (or complete) during your set timeframe.
For example, if your goal is to improve user engagement with your new product features, here are a few examples of sprint backlog items that'd support that goal:
- Provide interactive walkthroughs that guide users through the new feature.
- Trigger notifications for personalized recommendations based on user behavior and feedback.
- Offer points or achievement badges for new feature usage
2. Define your goals for the sprint
In a relatively short, clear statement, define what outcome you want to achieve during this upcoming sprint. This helps your team see the big picture and align on the overarching objectives that the next sprint will help achieve. The goals should support your roadmap and the overall project goal. To set effective goals, follow the SMART framework — and remember to get feedback from your team so you’re all aligned on the goals.
SMART stands for specific, measurable, achievable, relevant, and time-bound. When it comes to sprint goals, it’s especially crucial that they follow this framework. You don’t want to waste your precious sprint timeframe working on tasks that aren’t relevant at this point in the project. Nor do you want to set an unrealistic goal that'd typically take way longer than the allotted timebox.
Another important element of defining effective sprint goals is to create a user story for every feature you’re working on. The user story helps you tell what value that feature brings to your customer, user, or target audience. This is the “why” behind what your sprint aims to accomplish.
Related: How to write a sprint goal (with examples)
3. Determine team capacity
Knowing your team’s capacity is the first step in figuring out how much can be accomplished during your sprint. To determine team capacity, measure how many backlog items they can accomplish during a sprint.
Start by looking at individual availability through a realistic lens. This includes:
- Checking in on the energy levels of the team with their current workload
- Using feedback from individuals about workflows or challenges
- Accounting for time off work
- Keeping in mind that team members aren't doing hard, focused work for eight hours straight every day
- Considering any unplanned work that might come up during this sprint
Once you’ve gathered all of this information, you can add up everyone’s hours and forecast the total team capacity. Some leaders also use team velocity, a measure of the average production output during a normal sprint cycle, to calculate team capacity. But this number assumes that the tasks in each sprint will take about the same amount of time, and, therefore, they’ll be able to complete the same number of tasks.
Usually, it’s best to focus on the hours available to your team to avoid an incorrect prediction in your planning.
4. Estimate the work to be done
To estimate the work that needs to be done, look at each high-priority backlog item and discuss the effort, risks, complexity, and time necessary to deliver it during this current sprint. There are a few ways you can estimate work for an Agile project, including:
Time-based estimation
Each team member gives an estimate of the time it'll take to complete the tasks for a backlog item. They don’t need to be precise but rather use their best judgment based on the scope of the work and their experience working with a time limit. However, depending on the team member’s experience and the complexity of the tasks, you might end up with inaccurate estimates.
Story points
Collectively, the team assigns a point value to each item based on the complexity and effort relative to the other items on the list. For instance, a two-point story is “twice as much effort as a one-point story.” This approach allows team members to get on the same page about estimates without relying on skill level or experience.
Acceptance criteria
The Product Owner and development team create a list of acceptance criteria that need to be met for the item to be considered complete. You can think of it as a checklist to keep you on track and working toward the right goal. Having this list can also help you estimate how much work there is to be done.
Definition of “done”
As part of the acceptance criteria, create a definition of done based on the user story. This way, you can determine if the product or feature is ready to be released. For example, in our UX example mentioned earlier, “done” might mean that trigger notifications have been tested across numerous devices without any issues.
5. Assign work
Next, it’s time to decide which items can be included in the sprint and assign action items to team members. When discussing assignments, use language that emphasizes teamwork, like “Can we commit to this?” The onus isn’t on just one team member to agree to a certain task or backlog item. It’s a team process, and you’re all here to work together to achieve your goals.
However, it’s still important to be very clear and specific when giving individual team members direction. Here are a few best practices for assigning action items:
- Assign task owners or designate a single person to be in charge of getting that task done.
- Establish specific timeframes and due dates per task. Use a project management tool or put it on your calendar.
- Clearly identify which tasks have dependencies on other tasks, and connect task owners with each other if they aren’t already collaborating.
- Highlight potential challenges or risks to watch out for throughout the process.
6. Set a review date
Setting up a sprint review date in advance helps keep your team accountable until the end of the sprint. This review is like a retrospective; however, in addition to going over what worked and what didn’t, you’ll also have an in-depth discussion on how the sprint went, a demonstration of the new features or functionality, and answer stakeholder questions.
A sprint review is your opportunity to look at your previous sprint and make decisions about things like refining the backlog, experimenting with longer or shorter sprints, or providing your team with more resources for the next one.
Sprint planning templates: Time to get started
Mural’s sprint planning template helps you kickstart your sprint planning process and establish a team's goals and build a shared understanding of the projects included in a sprint. By the end of the session, your team will have a clear picture of what they'll be working on and what they'll be delivering next.
Template snapshot:
- Conduct a quick check-in to gauge how the team feels about the new sprint
- Review the product roadmap and backlog
- Prioritize tasks and build a project management plan
- Assign tasks to team members, align stakeholders, and track progress
- Conduct a final check-in and finish off the sprint planning session
Maintain visibility and momentum on a shared visual platform
The key to a successful sprint planning process is to keep everyone on the same page with a clear goal post to move toward.
A collaborative digital platform can help team members easily visualize and understand what’s expected of them during this sprint. Plus, it records your work, providing you with a history of the team members’ thoughts, comments, and feedback. This allows you to look back on how the process went and improve on the next iteration of the sprint.
Get everyone on the same page in your next planning meeting by running it on an visual work platform like Mural. This’ll get everyone engaged and on the same page, whether you're meeting in person or working remotely.