Last updated on | Agile

What Is The Sprint Planning And How To Have An Effective Sprint Planning Scrum Meeting

by Luís Gonçalves
sprint planning scrum


Over the last weeks I have collected a lot of feedback from my readers on what they´d like to read in next couple of weeks.  One of the topics was: how to run an effective sprint planning. 

For some of you this might be a basic topic, if this is the case, feel free to skip it 😉

Effective Sprint Planning Scrum Meeting

Any work that is to be performed in the Sprint is planned at the Sprint Planning. The plan brings together the entire Scrum Team and is created by collaborative work. Sprint planning is time-boxed to a maximum of eight hours for a month long Sprint

In Scrum, teams plan by picking up Stories from the product backlog. Afterward, they commit to a set of them for an execution in the upcoming sprint.

Like mentioned, each team plans the upcoming sprint in a time-boxed meeting (like in the most of Scrum Artifacts). It is a ScrumMaster´s responsibility to make sure that the event takes place and the attendants understand the reason for the event. The ScrumMaster will teach the team to stay within the time box.

By the end of the meeting (outcome) the team will have:

  • The sprint backlog, consisting of the stories the team committed for the next sprint. In an optimal scenario, these stories will have acceptance criteria.
  • The Sprint Goals
  • An agreement by the team to do what is possible to achieve the goals. The word commitment was removed in the last Scrum Guide. In my personal view, this was a great move.

The objective of the Sprint Planning Meeting is to organize the work and define a realistic scope for the next sprint.

Teams agree on a number of stories they can pull from the backlog. Of course, they must take the availability of team members into consideration. After agreeing on what they will take from the backlog, they define the Sprint Goal(s) together with the Product Owner.

Sometimes it is necessary to do some adjustments to achieve a larger purpose.

The team capacity is based on story´s complexity, size, and dependencies on other stories and other teams. We all try to get teams to have an end to end responsibility. Unfortunately, the reality is a bit different, and it is quite common to have several dependencies towards other teams.

Pre-Requirements for an effective Sprint Planning Scrum Meeting

Before the meeting, the Product owner should prepare some draft of the upcoming Sprint Goals. Usually, part of this task is done in the Grooming session.

Another important part is to be aligned with other Product Owners in case the team has dependencies on others. It is very frustrating for team members when Product Owners come to a meeting asking for work that cannot be done because of external dependencies.

It is not only the Product Owner that must do his homework. Team members must be prepared too. It’s common to have some research tasks (spikes) that must be done before the Sprint Planning. These tasks usually answer questions related to architecture or future implementations.

Guidelines for an effective Sprint Planning Scrum Meeting


Attendees of the Daily Scrum Meeting include:


An example of a Daily Scrum Meeting agenda:

  • The team determines the velocity available for the Sprint
  • If you use #NoEstimates, the team determines the number of stories they achieved in past (per sprint) and how many stories they could achieve based on their capacity
  • The Product Owner presents the Sprint goals; the team discusses and agrees on the goals
  • Personally, I find the previous topic a bit top-down approach 🙂 I prefer asking the team for the Goal, of course with the right guidance from the Product Owner
  • The team discusses each story. For each story, the team:
  • Sizes each story in story points and splits them if necessary
  • If you use #NoEstimates break the story until the team is comfortable to deliver the story up to two days
  • Elaborates acceptance criteria through conversation
  • Based on size and value/time/risk, the PO may re-rank stories
  • Some teams break the stories into tasks, estimated in hours
  • Planning stops once the team runs out of points
  • The team and PO negotiate and finalize the selected stories
  • Everyone commits to the Sprint goals


Usually, the Product Owner starts the meeting by reviewing the proposed Sprint goals. During the meeting, the team discusses the implementation and different options. In this meeting, the Product Owner is the responsible to define the what; the team defines how and how much.

During the meeting, the team elaborates on the acceptance criteria (together with the Product Owner) and estimates the effort to complete each story. 

Based on their velocity, the team then selects the candidate stories. Many teams break each story down into tasks and estimate them in hours to confirm that they have the capacity and skills to complete them.

As soon the team capacity has been established, the team turns their attention to understanding and agreeing on one or more sprint goals.

The product owner and team agree on the final list of stories that will be achieved. The sprint goals are then revisited and restated. The entire team commits to the sprint goals, and the scope of the work remains fixed for the duration of the sprint.

It is very important to mention that most of the times teams are over confident. They tend to pick more stories than what they were able to achieve in previous sprints. As a Scrum Master challenge them. Usually, they are not going to make it. This can lead to frustration and disappointment.

Hope you liked the post today. Some of you know that I have been studying for the SAFe consultant certification during last weeks. I found a very nice page about the Sprint Planning. I decided to re-write it to make it more look like Scrum 🙂 The original page can be found here.

Working with Me Or Evolution4all

I have developed the Organisational Mastery” product. The aim of this product is to create a coalition that drives change and internal innovation alongside shared knowledge throughout the organisation. It’s extremely suitable for companies that want drastically improve the alignment between executive leadership and delivery teams.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.


Share your point of view

  1. Good list 🙂
    Just wondered why the sprint goal should be discussed and agreed in beginning of the sprint planning?
    What happen if things changes during the sprint planning (e.g. discover stories were too big, new story pops up, etc etc)?
    Should we then agree on the Sprint goal by the end of Sprint planning again?
    I usually leave the Sprint goal to the end of the Sprint planning. Will be great to hear your view on it.

    1. Hi 🙂 Do not be so religious about it 😉 this is just a guideline…

      If things change during the meeting of course you adapt them 😉 But you should start the meeting providing some vision of what you want to do next sprint 🙂

      Thanks for commenting 😉

  2. @Shahab: Good point. But I think it is good to start with some Product Vision, refine it during the meeting and revisit it by the end, as Luis said.

    I have another one: IMHO the Estimations should not be the part of the Planning Meeting. The Product Backlog should have enough estimated Stories at least for the next Sprint, ideally for 2-3. So that the Planning Meeting can be dedicated to the planning only, not the Backlog grooming.
    And it also makes sense to divide the Planning into actually 2 meetings: Planning I (What, w/ PO) and Planning II (How, w/o PO).
    Will be great to hear your view on it as well.

    1. I think there is a confusion 🙂

      Of course estimation belongs to Planning its one of the mains parts 🙂 You can estimate in the Grooming but should be something much more on High Level 🙂

      Does not make any sense to estimate everything in the Grooming and just proceed to planning and do what you suggested. Most of the times Grooming works as research, team members use the space between Grooming and Planning to actually do research. Only then on the planning they do the final Estimation.

      I know a lot of people brake the Planning into Planning 1 and Planning 2 I personally never did it 🙂 I do not have any opinion if its good or not, I just did not find the need 🙂 but I like to keep the PO together with the team until the end 🙂


  3. Why I’m developing a Product Owner course is that they are plucked out of the business without Agile 101 and the team does the stuff you describe as their tasks in planning and backlog grooming. We will get there eventually.

  4. Yes, I find it very helpful for the team to have the PO talking about the direction he would like to go for this sprint. We also do it at the end of the previous Review meeting to share with all stakeholders where should coming next. So by having this direction at the beginning, you can accurately select the stories meeting this mini-vision and when not, you can remind you PO that this story meets no goal. Feel free to add it and adapt your goals. So update your goals during the meeting and at the end of the sprint planning the outcome should be clear, fixed to everybody to get started 🙂

  5. Yes, I find it very helpful for the team to have the PO talking about the direction he would like to go for this sprint. Btw, we also do it at the end of the previous Review meeting to share with all stakeholders what should coming next. So by having this direction at the beginning, you can accurately select the stories meeting this mini-vision and when not, you can remind you PO that this story meets no goal. Feel free to add it and adapt your goals. So update your goals during the meeting and at the end of the sprint planning the outcomes should be clear, fixed to everybody to get started 🙂

  6. Hi Luis!

    Great guidelines! Short and to the point.

    Teams traditionally dedicate 1 hour to sprint planning for every week of the sprint, discuss and commit goals. This time is used to assign backlog items for the upcoming phases of the sprint based on the team’s velocity or capacity and the length of the sprint.

    So, it’s very important to involve all key players to discuss and collaborate to get a more valuable outcome.

    Here is a step-by-step guide for sprint planning design using an online whiteboard:

    Your professional feedback would be greatly appreciated!