Skip to main content Skip to footer

Join us at Elevate ✨ Our virtual conference hits screens Dec 14th Join us at Elevate conference ✨ Tune in Dec 14th Register now

Project management

Optimize your sprint planning in 2023

All of us at 11 min read
Get started

What’s the fastest way a good Agile Scrum team goes bad? Simple: forgetting that the Agile methodology and the Scrum framework are supposed to save time.

Everyone from project management dabblers to the most hardened Scrum master is prone to this mistake.

Luckily, there’s a clear warning sign. The trouble starts when the timebox is no longer respected. Placing a timebox around your sprint planning meetings is more than a formality. Scrum literally isn’t Scrum without defined timeframes. But what if you can’t get everything done inside your pre-determined timebox? Well, that’s the hard part. And it’s the reason not everyone gets the Scrum framework right.

Don’t worry, though — in this article, we will tell you exactly how to get the most out of your sprint planning time. 

When should you do sprint planning?

A quick refresher: the Scrum framework divides projects into small sections called sprints, usually 1–4 weeks long. Each sprint starts with a sprint planning meeting.

During sprint planning, the project team reviews the work captured in the product backlog and figures out what items on the list they’re going to tackle in the upcoming sprint. At the end of every sprint, the project team holds a retrospective to discuss what went well and what could have gone better.

Then the next sprint begins with the next sprint planning session. The whole Scrum team should be involved in sprint planning, along with the Scrum master and product owner. It’s best to have it at the start of a week, so it leads right into 4 unbroken days of productivity. But that’s not essential.

For now, just remember that sprint planning starts every sprint.

Try monday dev

What is done in sprint planning?

The sprint planning session defines what will happen during the sprint based on what the Scrum team is capable of accomplishing. It also serves to get the entire team united behind the same sprint plan.

A sprint planning meeting usually kicks off with the product owner announcing the sprint’s goal. The product owner is responsible for making sure everything the team works on adds value to the product. They’ll decide on a goal that leads the product toward providing a greater value.

For example, if your project is to build a SaaS web app, the product owner might set the goal of launching a user dashboard by the end of the sprint. They’ll use that to demonstrate the value of the app to stakeholders. The team uses the sprint goal as a guideline to determine which items from the product backlog they’ll work on during the sprint.

The product backlog collects all the development team’s goals for the entire project. But if you try to work on all your product backlog items in one sprint, you’ll get nowhere. The sprint goal helps you prioritize.

Repeat until both parties are satisfied (at least, as much as possible). The product owner gets enough new features to provide value, and the project team has a small enough workload that they can put time into building things right.

The sprint planning template is a good visual example. sprint planning template

As sprint planning talks progress, the Scrum team leader and product owner can move items around the dashboard to represent what everyone has decided on. In our SaaS example, the product owner wants a complete user dashboard by the end of the sprint.

However, the development team knows that creating and populating the dashboard will take longer than 2 weeks. So, they talk the product owner down to an empty dashboard, which the owner can still show to shareholders and demonstrate value.

It’s a delicate balance, but with a few tricks, you can build a sprint planning session that works for everybody.

Try monday dev

How do you do sprint planning well?

Each item below is one of our best practices for sprint planning. We discovered them all through hard work and a lot of failing forward.

As we go down the list, we’ll also introduce some parts of the Work OS that make sprint planning significantly easier.

1. Get your backlog in order

One of the best ways to ensure an efficient sprint planning meeting is to have a 2nd, separate meeting beforehand. It’s a little counter-intuitive. Meetings to plan other meetings sound like the exact opposite of Agile methodology.

But there are some big reasons pre-meetings make sense. First of all, they don’t need to involve the entire Scrum team. A pre-meeting can be as small as the project manager (or Scrum master) and product owner. Next, a pre-meeting can foresee hazards that derail sprint planning if they come up unexpectedly.

Imagine you’re in the middle of sprint planning, and some members of the project team disagree about the meaning of a certain story in the backlog. Or, maybe they discover that they were completely wrong about where that story fell in the epic.

You’d better believe that sprint planning session is going to overflow its timebox.

Many Agile project teams have adopted a practice called backlog grooming, backlog refinement, or story time to help avoid this downward spiral.

In private backlog grooming sessions, team leads can reorganize the backlog to reflect the latest strategic priorities. They can also add clarifying context to any vague or ambiguous stories.

Sometimes, you might choose to invite your team to a backlog grooming session. In this case, the session gives them a chance to ask questions about each story before they have to factor it into a sprint plan. If you don’t want to eat up too much of your team’s productive time, though, we have another suggestion: the feature backlog template. feature backlog template

During a small backlog grooming session, a team lead and product owner can update the template. Any member of the team can then login and immediately see what changes have been made.

It’s a fast, visually pleasing way to get everybody on the same page for sprint planning. As a project manager, make sure you’re open to any questions your team might bring to you about it.

2. Schedule the retrospective separately

We know, we know: we’re asking you to have even more meetings. This is starting to sound like a Dilbert comic.

We don’t think the problem is the number of meetings, though. The problem is inefficient meetings. Meetings, stand-ups, 1:1s, and all the rest should be tightly controlled and placed where they’ll have maximum impact.

That’s why you should never do your sprint retrospective in the same meeting as your sprint planning.

Project managers often think they’re saving time by doing it this way. One sprint begins right where another one ends. There’s no use in having dead air in the middle. But this approach makes two mistakes.

First, it doubles the length of the meeting, risking lapses in attention when the important planning work begins. Second, the break isn’t dead air at all. The time between retrospective and planning is actually vital processing time.

On their own, your team members can digest the lessons from the previous sprint and experiment with ways to act on those lessons.

During the retrospective, use the sprint retrospective template to organize everybody’s thoughts. sprint retrospective template

We recommend letting at least a lunch hour elapse between the 2 meetings. Better yet, wrap up your sprint week with a retrospective Friday afternoon, and start your new week — and sprint — fresh with a Monday morning planning session.

After you’ve clearly presented the lessons from the last sprint in the template, a bit of time is all that’s needed to help them settle in.

Try monday dev

3. Assign values to each backlog item

Once the product owner sets a sprint goal, the team determines how much of it they can deliver.

For this part of the plan, there are a few terms you should get to know.

Velocity is a fundamental unit of sprint planning. It measures how much your team can get done during an average sprint. Everybody on your team should have a good sense of their own velocity.

Story points are a popular method for gamifying sprint planning. The point value for a task, or story, is a relative measure of how much effort it will take to complete.

Story points (SPs) are great for helping you compare work effort even when it’s too hard to give specific time estimates for tasks.

Scrum poker, or planning poker, is a process used to assign story points. To play, follow these steps:

  1. Give each team member cards with the numbers 1-10 printed on one side.
  2. Take all the backlog items you’ve determined to be part of the sprint goal and announce them one at a time.
  3. For each item, every team member puts in a facedown card with their estimate for its story points.
  4. The team lead shuffles the cards and turns them over. If all the estimates are relatively close — say, all 3s, 4s, and 5s — average the numbers to get the final estimate.
  5. If they’re not close — say, a 2 and a 9 for the same task — everyone who put in an outlier number claims it. In turn, they argue for why they gave their rating.
  6. Repeat steps 3-5 until there is a consensus.
  7. Move onto the next item until you’ve gone through every backlog task that fits the current sprint goal.

Scrum poker is a great way to reach consensus while still making everyone feel heard. If it seems too complicated right now, we recommend the Scrum planning template from scrum planning template

It’s a breeze to customize for a game of planning poker or however else you assign your story points.

Once you’ve assigned story points to every task, reaching a final scope for the sprint is simple arithmetic. Then it’s just a matter of doling the tasks out to your team and getting started.

4. Gather data over time

A sprint is not an island unto itself. Each sprint is an iteration of the one that came before. With each sprint, you have more accurate information about your team’s velocity.

The more you understand your past velocity, the more accurate your future projections become. For example, our R&D team at uses an approach where 1 story point equals roughly 1 day of work for 1 developer. For a 10-day sprint, we assign each developer 9 story points of work, leaving 1 free day to handle bugs or unexpected delays.

To keep this information handy, use a daily task manager. daily task manager

If your team members update this regularly at the end of every day, you’ll soon have a mountain of data on everybody’s velocity.

What should you do after sprint planning?

After a sprint planning meeting, be diligent about logging every decision your team made. Make sure to update the sprint scope, everyone’s individual tasks, every change to the backlog, and anything else that came up.

Sound like a lot of work? It is. Post-session bookkeeping can take up a team lead’s entire day. Fortunately, help is on the way, in the form of advanced workflow automations. We call it the Work OS. It’s a platform built by project managers that helps other project managers build the tools they need to save time.

Imagine if every story point estimate was automatically updated in the high-level project roadmap. Or if every task claimed by a team member went right into their daily task tracker.

In a Work OS, linked templates update each other, so every record of your project’s progress is always up to date.

Sprint planning final thoughts

The most important key to efficient sprint planning? Start before the meeting, and go into it with a plan. The 2nd-most important? Focus on your real team members, not some perfect Scrum ideal.

By collecting enough data to actually know your team, you can make sure your sprint plans get followed. That increases trust for the next one in a positive feedback loop.

Check out’s templates today to build the tools that will get you there.

Get started