Sprint Planning Meeting


TOPICS COVERED IN THIS GUIDE:

  1. What is a Sprint Planning Meeting?
  2. Who should attend a Sprint Planning Meeting?
  3. How long should a Sprint Planning Meeting last?
  4. Best practices on how to run an effective Sprint Planning Meeting
  5. Quick Summary

What is a Sprint Planning Meeting?

A sprint planning meeting happens before a Sprint begins. The entire scrum team come 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.

In short, 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.


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.

Here’s how each member will contribute to the sprint planning meeting

The Scrum Master

The role of a Scrum Master during a sprint planning meeting is to facilitate the meeting and make sure meeting rooms are book, supplies are available, and people are prepared before the meeting. From a facilitating and scheduling point of view, the Scrum Master timeboxes the sprint planning meeting based on the sprint’s duration.

For example, if the sprint’s duration is 4 weeks, the sprint planning meeting should not exceed 8 hours. Of course, it would be hard for the team to do this in one sitting. So the Scrum Master should take the responsibility of appropriately managing the time and ensure there is complete alignment on the sprint goal and sprint backlog at the end of the meeting.

The Product Owner

The Product Owner is responsible for coming up with an updated backlog before the meeting. Their role during the meeting is to clarify questions and details on item. Since the product owner will have the maximum context, they should be help the team understand the use case and come up with an acceptance criteria for each item. As someone who will be answering question and clarifying doubts, it is therefore essential for a product owner to be equipped with any and all information they might need and come prepared.

The Development Team

Of course, the people who will be executing each of these items in the sprint should be a part of this meeting. That could be anyone — designers, developers, QA team, marketing, sales, customer support.

Irrespective of the team they belong to, if they’ll be executing any of the user stories or tasks in the sprint, they should be part of the sprint planning meeting. Bringing them onboard early ensures they get a full understanding of what they’ll be working on and more importantly and why they’ll be working on something.


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.


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.

2. Have a groomed backlog

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.

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

Description for a user story in Zepel

Add details to a user story in Zepel with descriptions

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.

Plan Sprints in Zepel

Sprints in Zepel

In Zepel, once you’ve added items into a Sprint, set a start and an end date for your Sprint based on the total estimate. This will ensure that everyone can see how the sprint is progressing and know who is responsible for what.


Quick Summary

Summary of Sprint Planning Meeting



Vikash Koushik

Vikash Koushik

Product Marketing at Zepel.io