software teams

Sprint planning meetings

How to run sprint planning meetings that don’t suck

Who you need

  • Scrum Master (usually a lead engineer)
  • Scrum Product Manager/Product Owner
  • Scrum Team (engineering squad)

How long it takes

  • 15 minutes prep
  • 1 hour meeting for each week of the sprint
  • 15 – 30 minutes post-meeting documentation

Sprint planning meetings are regular sessions where your scrum team decides which backlog items to prioritize in the next sprint, what you can realistically expect the team to achieve, and how the team will tackle those items. Here’s how to run yours.

Before the sprint planning scrum

1. Revisit company and team goals

Without a foundational understanding of what customer value the company and your team need to deliver, planning meetings simply can’t succeed. So make sure you are up-to-speed on the latest company goals and user personas and ask the team to review them before attending your meeting.

Even if your goals and personas aren’t changing as often as you plan sprints, reminding the team of these foundational truths is an important step. In a recent study by MIT Sloan, only 28% of leaders could accurately list three of their company’s top strategic priorities. While there are likely multiple reasons for this disconnect, one simple fix to keep teams aligned to organizational goals is to revisit them (briefly) every time you start a new planning cycle.

Alternately, you can spend the first five to ten minutes of your meeting going over this information. But if your goal is to keep meetings short and sweet, asking teams to review goals ahead of time can help keep things snappy (not to mention it gives teams more time to marinate on any questions, concerns, or ideas they want to bring into the meeting).


For a deeper dive into why sprint planning matters and what best practices to live by, check out our ultimate guide to sprint planning.

2. Refine the backlog 

During the planning meeting, your team will be going through the backlog. If it’s messy, the meeting will also feel messy. Which is why the product owner/manager should review the backlog ahead of the meeting, removing things that clearly no longer need to be there, adding anything important that’s missing, and perhaps even doing some pre-prioritization based on the organization’s goals.

The best way to handle this is to schedule dedicated time to clean up the backlog prior to the sprint planning meeting. Even if this adds a bit of work to the pre-meeting process, it’s worth it in the long run to keep meetings nimble and less bogged down by unnecessary detail.

The more refined your backlog, the faster and happier your meeting will be. After all, it’s way easier to prioritize a list of 20 items than it is to review 100, 50 of which are no longer even relevant.


Remember that scrum is all about clear goals, collaboration, accountability, and delivering incremental value. How you run your meetings should reflect these foundational values.

Running your sprint planning scrum

1. Set the context of the meeting

If teams have already reviewed your goals, you don’t have to spend too much time on this. But make sure the product owner and/or scrum master kicks off the meeting by reminding the team about the goals of the meeting itself. You should plan to leave your meeting knowing:

  • The overall goal of the sprint

  • Tasks included in the sprint

  • Who is responsible for these tasks

  • Dependencies identified for the sprint

  • Risks identified for the sprint

  • How you’ll track success

  • Contact information or channels for communication between individuals and teams involved in the sprint

This is also the time to share any other key information the team will need in order to effectively plan all of the above (for example: if part of the team will be on vacation and unavailable for assignments, this is the time to bring it up).

2. Define your sprint goal

This is also the time to define the goal of the sprint itself. If your team only leaves the meeting with one thing, it should be an understanding of the goal of the sprint and how the sprint will take them closer to that goal.

Sprint goals should be one to two sentences that briefly describe what your sprint should achieve. For example:

  • Reduce customer churn by 15% by building a virtual assistant that can solve the most common customer problems.

  • Increase customer sign-ups by 25% by simplifying our sign-up process.

Once you have your high-level sprint goal on paper, it’ll simplify the process of prioritizing your backlog and facilitate an understanding of how each task contributes to a larger vision.


Check out our free sprint planning template, where you can document not only the sprint goal but everything else from your planning meeting.

3. Discuss velocity and capacity 

How much work has the team completed in the last few sprints? Are there any resource or personnel changes or responsibilities that will impact capacity? Check in with the team on these questions before deciding how much you can reasonably tackle in your next sprint.

4. Review the backlog and set priorities 

Now comes the meat of the meeting. It’s time to review the (hopefully refined) backlog and decide which items are priorities based on organization goals, user needs, and team abilities.

This is also the time to provide estimates. How much time will each backlog item take? And how does that fit into the velocity and capacity expectations you’ve identified? There’s more than one way to estimate, but many teams use t-shirt sizes or story points for the sake of simplicity.

5. Assign work 

Who will work on which items? How will you split up responsibilities? How does each person or team’s workload impact the others? How will the work get done and in what order? This is the time to hash out those answers and set reasonable expectations for what can get done.


This isn’t the time to shoot for the moon. Make sure when you plan a sprint you aren’t overloading your teams, ignoring key dependencies, or assuming a higher velocity than you’ve ever reached before. It’s great to set stretch goals high. But ultimately there should be a realistic, reachable goal that you use for planning purposes.

6. Document risks and dependencies 

Identifying potential risks, dependencies, and bottlenecks now will help product owners and scrum masters keep an eye on potential trouble spots so that they can head off any issues before they derail your project.

7. Define your metrics for the sprint 

How will you measure the success of your sprint? Ask the team to define metrics for success based on organizational goals, expected user value, and the backlog items you’ve prioritized.

8. Get team agreement 

Before you leave the room, make sure everyone understands not only their responsibilities but the overall projects and goals. Then make sure that everyone is on board. If there are still major concerns, they need to be documented. If there are lingering questions, you may choose to answer them now or circle back with individuals or teams later with answers or for a longer discussion.


An added benefit of good sprint planning scrum meetings? Bringing the team together! 52% of employees say they felt disconnected from their teams at some point in the past year, so this regular connection can add real value to team solidarity.

After the meeting

Document your plan

Someone (often the product owner or scrum master) should be responsible for documenting the results of your meeting and making sure everyone has access to that documentation. Some of this might happen during the meeting, with some cleanup and review afterward. Some of the things you’ll need to document include:

  • The overall goal of the sprint

  • Tasks included in the sprint

  • Who is responsible for these tasks

  • Dependencies identified for the sprint

  • Risks identified for the sprint

  • How you’ll track success

  • Contact information or channels for communication between individuals and teams involved in the sprint

This person will also likely need to set up any tracking or metrics you’ll be using to measure that success or flag in your systems if things start to go off track.

Simplify your scrum with a template

As with any meeting, the shorter and more efficient it is, the happier teams will be. Which is why we’ve developed templates you can use to shortcut the process. Streamline your entire Agile process with our Software Development Template.

Related Resources

Product roadmap template guide

Your complete overview to launching a successful, preconfigured product roadmap with ClickUp.

Sprint planning for agile project managers

A deep-dive guide on everything you need to know about successful sprint planning.