How to run an effective Sprint Planning Meeting?

The main goal of the sprint planning meeting is to walk away with two things:

1. Sprint goal: Agree on what will be delivered at the end of the sprint.
2. Sprint backlog: A prioritized set of user stories, enhancements, bugs, tasks, and sub-tasks for the up-coming sprint that will help the team focus and deliver.

What is a Sprint Planning Meeting?

A sprint planning meeting is one of the scrum ceremonies. It happens before a Sprint begins. The entire scrum team comes together during this meeting, discuss, and agree on what they’ll deliver in the upcoming sprint.

During the sprint planning meeting, the product owner explains the highest priorities, helps the development team understand why the user stories are important, and how they’ll impact users.

With this knowledge, the development team asks questions to get a better understanding of the users needs, and try to break down the user story into actionable pieces of work with an estimate on how long it’d take to build it.

Who should attend a Sprint Planning Meeting?

All members of the sprint should attend the sprint planning meeting. That is:

1. The Product Owner
2. The Scrum Master
3. The Development Team

When you’re discussing to agree on what everyone will deliver at the end of the sprint, it’s best to get everyone’s input and perspective before you move forward. After all, you wouldn’t want to miss any edge cases.

How long should a Sprint Planning Meeting last?

According to Scrum Guide, the sprint planning meeting is time-boxed to eight hours for a one month sprint. If your sprint is shorter than a month, sprint planning meeting is reduced proportionately.

For example, a two-week sprint should not have a sprint planning meeting that exceeds four hours.

But does that mean you must spend eight hours planning for a month-long sprint?

If a meeting concludes before the time allotted, end the meeting and leave! Don’t try to fill the time with other random top of mind topics. ~ Paul Adams, VP of Product at Intercom

As long as your team is on the same page on what will be delivered in the upcoming sprint, it’s alright if your meeting ends in an hour. Remember, principles support your business. You shouldn’t mould your business around them.

How to run an effective Sprint Planning Meeting

Step 1: Prepare for Sprint Planning Meeting

Preparation for sprint planning meeting is different for a product owner and a scrum master.

As a part of preparation process for the sprint planning meeting, the product owner should make sure the highest priority user stories have acceptance criteria written and are updated. The highest priority user stories are derived from the product roadmap and the company goals. This means the product owner should make sure the highest priority user stories also align with the roadmap.

The product owner should categorize user stories together that form a single feature. This is important because with all similar user stories grouped together as a feature, it helps the product owner to see how they connect back to the company’s goals. This product backlog of prioritized and updated user stories acts as the input to the sprint planning meeting.

The scrum master on the other hand prepares for the sprint planning meeting by making sure the meeting room (or conference call) is booked and scheduled, everyone has the necessary supplies, and ensures all members of the team come prepared for the meeting.

Step 2: Collaboratively brainstorm and estimate user stories

During the sprint planning meeting the product owner shares the highest priority user stories, why they are the highest priorities, and how it connects to the roadmap.

Once this is done, the development team will break the user story down to actionable subtasks and estimate them using story points. The development team uses this opportunity to ask more details about the user story to estimate effectively.

Step 3: Define the sprint goal and add user stories to the sprint

It’s important that a product owner comes with a loose sprint goal to the sprint planning meeting. But it’s essential that it stays as a loose sprint goal. Because to decide the sprint goal the product owner needs to know the estimation points. And a sprint goal without clear estimations is only wishes of the product owner.

With the estimation from the development team, the scrum team can identify what are the most fundamental user stories that must be built and what are nice to haves. Based on this, the estimation from development team, and the sprint duration, the team should be able to come up with a prioritized list of user stories that will help the team achieve a goal.

Best practices on how to run an effective Sprint Planning Meeting

1. Bring your learnings from the previous Sprint

If you ran a sprint prior to the one you are currently planning, you most likely found areas you’d like to improve by running Sprint Retrospective Meeting. Be sure to bring it up during the sprint planning meeting and see how you can implement changes to your upcoming Sprint to improve your process.

If your team is relatively new to Scrum, it might also be good to have a look at your previous sprint burndown chart to see how your team made progress.

2. Have a groomed backlog

Backlog grooming is essential to the entire scrum process. Before the sprint planning meeting, make sure the backlog is groomed with fully formed user stories and the most important work listed at the top. It’s best done a few days before the sprint planning meeting with just the product owner and the scrum master.

This allows the product owner and scrum master to fill details and context to user stories that might not be fully formed and come prepared for the sprint planning meeting.

3. Tell a story

As a product owner, keeping in mind that each backlog item is a user story and not a bunch of features could make a world of difference, especially when you’re trying to explain it to your development team.

Showing your dev team where the problem occurs in the user’s current solution and why it’s a pain will help them get a clear picture of what they need to be working on.

After all, the sprint planning meeting is a way for the product owner to convince the rest of the team on what the highest priorities are. And what better way to convince people than telling a story?

4. Drill down to the details

When you drill down to the details of a user story by breaking it down to tasks and subtasks, the entire team gets an idea of the complexity involved in building it. Besides, breaking down a large chunk of work into tiny pieces of actionable work makes estimating your work much more easier.

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

5. Get approval and align everyone on the same page

Once your development team breaks your user stories down to tasks and subtasks, and you have an estimate of how long each of them will take, you should ideally be able to come up with a Sprint backlog that you can add to a Sprint.

Be sure to add each work item to a Sprint on your project management tool and ensure each member has at least one item to work on and nobody is duplicating work. Once you’ve added items into a Sprint, be sure to reiterate the goal for the Sprint and show your team the list of work items the team will be working on.