There are few things that are as crucial as running a well executed sprint planning meeting.

Get it right and you’ll be on your way to shipping quality software. Get it wrong, and it'll snowball into a giant mess.

Development workflows in businesses are already ridden with inefficiencies due to misalignment of teams, tools, and processes. And running an effective sprint planning meeting can be your first step to streamlining your development process.

But more than that, a sprint planning meeting is critical because it aligns the development team with the product owner. Much like all relationships, the one between you and your team requires communication and clarity.

And what better way to take the time to sit down and ensure the expectations are understood and can be done by your team?

This article will walk you through 5 steps you can follow every time you run a sprint planning meeting. It’s the only template you’ll ever need.

Step 1: Mind the roadmap

The best way to make sure your sprint is successful is by not thinking only about your sprint, but about your product as a whole!

This, of course, is easier said than done. As a product manager, you’re tasked with keeping track of the micro level changes that your team makes (think tasks and user stories) and connecting it with the macro level goals you need to accomplish (think, product roadmap and vision).

How do you zoom in, zoom out, and make sense of all the updates from design, development, and QA teams? How do you do it when all their work is split between sticky notes, simple task lists, and inside GitHub?

The key is to ask yourself some serious questions:

• Is your roadmap of feature derived from a product strategy that moves the needle?
• Are you reacting to loud customers? Or are you prioritizing the right features?
• As your team completes multiple sprints, how is effecting your entire roadmap?

There are always too many features you can build. But as a product manager, it’s your job to say no. If you want to build a product that stands out, you’ll have to make sure what your team is building today will take your product to where you want to be at the end of this quarter, 6 months, or a year later.

Zepel offers a unique way for you to keep plan your roadmap and track of its progress effortlessly, even as members from multiple teams make changes and progress.

Step 2: Have an updated list of user stories before sprint planning meeting

In a perfect, simple world, your team can pick up the user stories you wrote a month ago and start working on them immediately. In reality, that’s rarely the case.

Since the last time you wrote the user stories, your customers would’ve asked for several functionalities to be added to your feature and their usage within your product would’ve changed. You’ll have to factor in all these variables and changes into your user stories and ensure they are updated before you walk into the spring planning meeting.

Now, the question most teams have is “how many user stories should you update?” The ideal case is to have all of them updated. But in reality that’s an impossible task unless your product is relatively new and small.

The best practice is to have enough user stories updated to plan the next two sprints. That way, you’ll have the context of what the sprint is building towards — ideally, towards hitting your roadmap goals you reviewed in the previous step.

If you’re using Zepel , you can quickly add more details to your user story by adding detailed acceptance criteria, attachments, and comments. That way, when you bring your teammates, everyone has the full picture of what each user story tries to achieve and everyone is on the same page.

Step 3: Estimate user stories and tasks

Now that you’ve updated your user stories, it’s time to bring in your development team and estimate how long it would take to complete each of these user stories you updated. Estimating accurately is one of the hardest things to do.

Of course, not every user story will be hard to estimate. In our experience, we’ve noticed things we have past experience working with, are much easier to estimate. A huge reason for this is the fact that our team is already equipped with the working knowledge and the intricacies involved in building it.

When working on things we don’t have previous experience with, we make sure we break the user story down into subtasks and estimate each of those subtasks. Once we break the user story down, we take a step back and look at all the tasks. Often times, we notice there are a bunch of work that we can start working on immediately, few that look vague, and a couple that look as mysterious as the dark side of the moon.

We group each of them into three categories — known, partially known, and unknown — and work our way to finding more information about them.

When you haven’t thought about what you’re going to do, you can’t know how long it will take.

~ Joel Spolsky, CEO of Stack Overflow

We’ve written a beginner’s guide to estimating a user story with story points over here. And shared some best practices you should follow over here.

Step 4: Come up with a clear sprint goal

With all user stories updated and estimated, as a product manager everything should slowly start to make sense like an M. Night Shyamalan movie.

While you might have an initial objective in mind for the sprint, coming up with a sprint goal is really a collaborative effort. A sprint goal, simply put, is what you would’ve delivered at the end of the sprint. They’re a great way to get your team to rally around a common goal and keep them motivated.

An example of a sprint goal may look like this: “Develop the checkout process for the story”.

But before you even begin discussing about what the goal of the sprint should be, make sure that you’re setting the right expectations for the sprint depending on the sprint duration. That means, understanding your team’s capability, factoring in unforeseen delays, and setting aside some time for bug fixes, code reviews, and optimizations.

As we get deeper into running a sprint planning meeting you need to remember:

Your sprint goal intersects with your customer’s problem at specific touch point. The software you deliver at this intersection is another opportunity to “wow” them and gain their loyalty.

Step 5: Collaboratively plan a sprint backlog

With a sprint goal in place, it’s time to talk about “how” you’re going to achieve it.

This basically is a collection of multiple user stories you updated and estimated in the previous steps. The difficulty is identifying a list of user stories, tasks, and bugs that will help you achieve the goal and can be completed within the sprint duration.

It’s essential the team collectively selects the sprint items and size of the sprint backlog. Since they’re are the people committing to completing the items, they must also be the ones to choose what they are committing to.

When you involve your team in the sprint planning process, you don’t have to run behind them every other day asking for updates. Because they’re motivated by a far greater power — extreme ownership.

Of course, once your sprint backlog is finalized, make sure you to assign, set due dates, and share all the assets your team needs to do their best work.

Key points to remember during sprint planning meeting

1. The sprint planning meeting is a collaborative effort.
2. According to scrum guide, the sprint planning meeting should be time boxed to 8 hours for a sprint that’s 1 month long.
3. As a product manager, be sure to discuss and specify acceptance criteria for each user story.

Sprint planning template: So you can streamline the entire process!

Here’s a sprint planning template you can use that uses all the best practices we discussed above.

A sprint planning template should enable teams to get a quick overview of what's planned for the upcoming sprint along with its details. A template should include the following 6 parts to help teams effectively plan their sprint:

1. The sprint name: This is helps teams understand the goal of the sprint.
2. An overview of the sprint: This includes its duration, status, number of open items, estimates remaining, and a completed percentage. It's helpful before you begin the sprint to see the amount of work your team will be working on. It's also helpful to give you a quick report of the update when the sprint is in progress.
3. Sprint reports: The burnup and burndown charts based on estimates or count helps product managers get a deep understanding of the progress.
4. Scrum boards: Enables teams to track each item in a board.
5. Items: A list of items in the sprint along with its properties, such as assignees, due dates, and estimates.
6. Description, comments, and attachments: An icon next to an item indicating it has more details in it.