Sprint Planning
Last updated on 2026-10-14 | Edit this page
Overview
Questions
- How to prepare for Sprint Planning meetings?
- How to conduct Sprint Planning meetings?
- How is the Sprint Backlog created?
Objectives
By the end of this chapter, you will be able to:
- Understand the purpose and structure of a Sprint Planning meeting in Scrum.
- Understand and define clear Definition of Done (DoD).
- Define a clear and achievable Sprint Goal using the SMART criteria.
- Identify candidate backlog items that align with the Sprint Goal.
- Estimate Story Points for each user story using Planning Poker.
- Validate the Sprint Goal and sprint scope based on effort estimates.
- Create a Sprint Backlog and commit to the sprint, including Stroies and priorities.
- Collaborate effectively as a Scrum Team to plan and commit to a realistic sprint.
4.1. Introduction
To recap from previous Chapters, you’ve learned how to move from the Product Discovery phase to defining and organising stakeholder needs through the Product Backlog. You worked with the Product Owner (P.O.) to translate these insights into clear, prioritised User Stories. Through Backlog Refinement, you developed these stories further by breaking down large Epics into smaller actionable items, adding descriptions and acceptance criteria, and ensuring each story aligns with business value.
Now, it’s time to move forward. In this next chapter, you’ll learn how to take that refined Product Backlog and plan your Sprint. In Scrum, a sprint is a short, time-boxed period during which the Scrum Team works to complete a set of product backlog items. Sprints typically last two to four weeks.
Sprint planning is a Scrum event held at the beginning of a sprint to set expectations for upcoming work. The team collaborates to define sprint goals, determine what work can be accomplished within the sprint, and outline the steps for completing the necessary tasks.
The key participants of the Sprint planning meetings are the P.O., the Development Team and the Scrum Master.
- The P.O. defines the sprint goal (we will cover it in detail in the section below) based on the value that they seek and what backlog items contribute to that goal.
- The Development Team needs to understand how they can or can’t deliver that goal.
- The Scrum Master chairs the meeting, ensuring that the planning process is followed and that everybody participates and understands.
Sprint planning should be constrained to no more than two hours for each week of the sprint. So, for example, the sprint planning meeting for a two-week sprint would be no longer than four hours.
Here is a reminder of the slide that visualises the Sprint Planning meeting. 
Image Source: Agile Methods for
RSE
The input to the Sprint Planning is the refined Product Backlog.
The outcome of the Sprint Planning is a Sprint Backlog, created after the team agrees on a clear Sprint Goal and understands how they will work toward it.
4.2. Prepare for the Sprint Planning Meeting
Note: If you are about to plan your first sprint, you can skip Section 4.2 and head straight to Section 4.3.
Before you jump into Sprint Planning, take a moment to remember the lessons from your last sprint. The improvements your team identified during the Sprint Retrospective Meeting should guide how you plan and work in the new sprint. This helps you avoid repeating old mistakes and encourages continuous improvement.
Challenge 1: Review Retrospective Actions (1 minute)
- Look at your Retrospective Wall created at the end of the last sprint.
- Review the action plan so you remember what the team agreed to start, stop, and continue doing.
- Keep these actions in mind throughout the upcoming sprint and actively work on them as a team.
- Scrum Master: It is your responsibility to remind the team of these commitments and help ensure improvements to team dynamics, processes, and tools are followed through.
4.3. Conduct the Sprint Planning Meeting
In this section, we will take a closer look at the Sprint Planning process, how a Scrum team collaborates to plan a sprint, define what work will be done, and determine how it will be accomplished.
The main steps in the sprint planning meeting are:
- Define the Sprint Goal
- Identify candidate backlog items
- Estimate Effort / Story Points
- Create the Sprint Backlog & Commit for the Next Sprint
We will explore each of these activities in detail below, with hands-on exercises to practice and understand them. You will also see examples using the same “Rental Booking” product featured in Chapter 3 for demonstration purposes.
It is worth noting that:
- Steps 2, 3, and 4 in the Sprint Planning Process are iterative: after estimating effort, the team may need to adjust which backlog items are included.
- Sometimes iteration may loop back to Step 1 (Define the Sprint Goal) if major adjustments affect what can realistically be achieved.
- During the Sprint Planning session, the Sprint Goal is not fixed; it should be validated and updated if necessary, before the sprint begins.
Before we can decide what to plan for the sprint, there is one critical question the team must align on:
How will we know when work is truly finished?
Without a shared understanding of what “done” means, teams risk planning work that cannot realistically be completed within the sprint, underestimating effort, or disagreeing later on whether a user story is complete. This often leads to unfinished work, rework, and frustration during the Sprint Review.
To avoid this, Scrum teams establish a shared agreement called the Definition of Done (DoD) before committing to sprint work.
4.3.0. Definition of Done (DoD)
- The Definition of Done includes all of the characteristics and standards an Increment needs to meet in order to be released.
- The DoD should be inspected and adapted at the Sprint Retrospective.
How do you start the Definition of Done?
The DoD starts with organisational standards that all teams must follow as a minimum. That infers that teams can add to the organisational DoD but cannot omit items from it. If multiple teams work on one product, they comply with the same DoD, but each team might have additional items in their DoD.
Difference between DoD and Acceptance Criteria (AC)
- The DoD is a set of high-level criteria for determining if a product increment is complete. It applies to all product increments and defines the overall quality of a product.
- In contrast, acceptance criteria are low-level conditions that apply only to specific user stories or features. AC defines whether a user story is acceptable to a customer.
- Acceptance criteria are assigned to each Product Backlog Item (PBI).
- An example of DoD could be: “All documentation is written and updated.”
- An example of AC could be: “The link to the user documentation is accessible from the navigation menu.”
Note: For further details on DoD you can watch this Video
Challenge 2: Create Your Team’s Definition of Done (5 minutes)
Note: This Challenge only needs to be done in Sprint 1. For the rest of Sprints teams will be inspecting and adapting their DoD during the Sprint Retrospective.
- As a team, think about everything that must be completed for a product increment to be usable and valuable. Write each activity or condition on a separate sticky note and place them on the board.
- Group similar or duplicate items together.
- Discuss and clarify any items that are unclear or ambiguous.
- Ask: Is this required for every user story to be considered done?
- Agree as a team on which items should be included in your Definition
of Done.
- Remove items that describe how work is done (tasks) rather than when it is done.
- (Don’t throw these items away! They might be useful then defining Acceptance Criteria on upcoming tasks.)
- Take a team vote to confirm that everyone agrees with the Definition of Done.
4.3.1. Define the Sprint Goal
During sprint planning, teams can easily get stuck discussing small details, like which task to do first, who should do it, and how long it will take. That’s where the sprint goal helps.
A sprint goal explains the purpose of the sprint. It gives the team a shared objective and reminds everyone why the sprint is worth doing.
So far in this course, your goal has been to work toward a Minimum Viable Product (MVP) or first release. Remember that:
- You don’t have to finish all the MVP user stories in one sprint.
- A release can include multiple sprints, depending on how much work is needed.
Creating the sprint goal is the P.O.’s responsibility, but it should be done together with the whole Scrum Team, including the Development Team, Scrum Master, and Product Owner.
The concept of SMART plays an important role in setting sprint goals. SMART stands for
- Specific
- Measurable
- Achievable
- Relevant
- Time-bound
Following SMART ensures that you set attainable goals that provide measurable results and contribute to your larger organizational objectives.
You can see examples of sprint goals for the ‘Rental Booking’ product in the image below:
4.3.2. Identify Candidate Backlog Items
Once the Sprint Goal is clear, the next step is to identify the user stories that will help achieve it. The P.O. presents the high-priority items from the product backlog, and the team discusses which ones best support the Sprint Goal.
Examples of candidate backlog items for the Sprint Goals defined for the ‘Rental Booking’ product are shown in the image below:
Challenge 3: Define the Sprint Goal & Identify Candidate Backlog Items (5 minutes)
As a team, work with your P.O. to define a clear Sprint Goal.
Decide:
- What specific capability or outcome should be delivered by the end of this sprint?
- How will we measure whether the Sprint Goal has been achieved?
- Is the goal realistic given the sprint duration?
Identify Candidate Backlog Items:
- Review the product backlog and identify the user stories that will contribute to achieving the Sprint Goal.
- Discuss and agree on a shared Sprint Goal that everyone understands and supports.
Further Instructions:
- Scrum Masters: Ensure that all team members actively participate in the discussion.
- Make sure the Sprint Goal follows the SMART criteria described above in section 1.
- Online participants: Use the “sprint goal candidate” tag in the Miro board to mark the identified user stories.
4.3.3. Estimate Stories with relative Story Points
Sprint planning requires some level of estimation. A Story Point is a number that represents:
- Volume: How much there is
- Complexity: How difficult it is
- Knowledge: What we know
- Uncertainty: What’s not known
Story points are relative, and are not connected to any specific unit of measure.
Planning Poker is a game used to obtain a consensus on how long each User Story will take to complete. Each team member has a set of poker cards with a time estimation written on the back (e.g., ‘don’t know’, ‘infinity’, 0, ½, 1, 3, 5, 10, 13, 20, 50, 100’). In this scale, smaller numbers (e.g., 1) indicate that the story will take less effort, while larger numbers (e.g., 20 or 50) indicate that the story will take more effort.
A team can only make estimations based on what they have learnt so far. As more sprints are completed, the team’s ability to predict and reach a consensus on how long tasks will take will improve.
To play Planning Poker, the following steps are repeated for each User Story that could contribute towards the Sprint Goal:
- Each player estimates the relative effort required for the User Story and plays the respective card face-down, so nobody can see.
- When every player has played a card, they are all turned over simultaneously and the answers compared. Team members are invited to explain why they chose their estimates, particularly those with very different answers to the rest of the team.
- Steps 1 and 2 may be repeated until a consensus is reached amongst the whole team.
- The agreed estimate (in story points) is added to the User Story.
Important things about Story Points
- Story points measure volume, complexity, knowledge, and uncertainty, not exact hours or days.
- Estimates are relative — compare all stories to the smallest story in the list, not to a fixed time.
- Example: If Story B is roughly twice as complex as Story A, it gets about twice the points.
- Story points help teams plan, address uncertainty or risk, and commit to achievable work, without bias or emotional attachment.
- Story points reward team members for solving problems based on multiple measurements, not simply time spent.
Challenge 4: Estimate Stories with relative Story Points (10 minutes)
As a team, estimate the effort required for the selected candidate user stories in relation to your Sprint Goal from Challenge 3 above.
Decide
- Evaluate each story for how much work there is (volume), how difficult it is (complexity), how familiar the team is with the work (knowledge), and what is unknown or risky (uncertainty).
- Use Planning Poker to estimate story points relatively, by comparing each story to the smallest or simplest story (ideally, start with a simpler story first so this measure can be approximated).
- Reach a team consensus on each story’s estimate.
- Estimates should assume that each story meets the agreed Definition of Done (DoD).
Follow the steps of the Planning Poker game outlined above (1–4).
Further Instructions:
- Online participants: Use the Planning Poker tool on the Miro board to do this (instructions for how to play are on the board itself).
- If a consensus cannot be reached after a few rounds, set the story aside and create a secondary task to clarify it later.
- Scrum Masters: Ensure all team members participate, explain their reasoning, identify any risks that could make the story complex, and work toward a collaborative decision after listening to everyone.
Challenge 5: Validate Sprint Goal & Sprint Scope (5 minutes)
As a team, review the Sprint Goal and the identified backlog items against the Sprint Goal in light of your effort estimates.
Decide:
- Based on your estimates, can all the identified items/User Stories realistically be completed within the sprint duration?
- Can all selected stories realistically meet the Definition of Done (DoD) within this sprint?
- If the sprint seems overloaded, discuss and negotiate with the P.O.
to:
- Remove or defer some backlog items
- Adjust the Sprint Goal if necessary
Further Instructions:
- Scrum Masters: Facilitate the discussion to ensure everyone participates.
- Focus on achieving a realistic, committed plan rather than trying to fit everything in.
4.3.4. Create Sprint Backlog & Commit for the Next Sprint
The Sprint Backlog is the set of user stories that the team commits to completing in the upcoming sprint and it includes:
- The user stories or product backlog items selected to achieve the Sprint Goal.
- The effort estimates and priorities agreed on by the team.
The process so far in defining the Sprint Goal, selecting candidate backlog items, estimating effort, and validating scope has laid the foundation for creating a realistic, actionable sprint backlog.
Referring back to the introductory presentation, we can see that we now have the information required to create the Kanban style sprint backlog, as shown below:
Image Source: Agile Methods for
RSE
Challenge 6: Create the Sprint Backlog & Commit for the Next Sprint (5 minutes)
Now that the Sprint Goal is validated and effort estimates are known, it’s time to create your Kanban-style Sprint Backlog.
- On a whiteboard or Flip chart (physical or digital), create four columns: To Do, In Progress, Blocked, Done.
- Move all user stories and tasks that were selected to go into the Sprint Backlog, into the To Do column.
- As the sprint progresses (in the following episode), team members will move tasks from To Do → In Progress → Done or Blocked if required.
Further Instructions:
- Scrum Masters: Ensure all team members agree on the stories in the Sprint Backlog and understand each one.
- Online participants: Use the relevant Kanban board in the Miro board for the current Sprint; remember that (1) you can duplicate elements from the User Story Map into the Kanban board (but not vice versa), and (2) you need to sync any changes following the duplication manually between the Kanban board and the User Story Map.
Image Source: Agile Methods for
RSE
- At the start of each sprint, there is a Sprint Planning Meeting
- The Sprint Planning Meeting is attended by the Scrum Team: The Product Owner, Scrum Master and Development Team
- The Product Owner ensures that the highest priority User Stories are highlighted.
- The definition of done (DoD) is a shared set of criteria that determines when a product increment is complete and ready for release.
- A clear DoD ensures quality, minimizes rework, and aligns team members on expectations for completion.
- DoD should be collaboratively defined, visible, and regularly updated as the team learns and evolves.
- The Development Team add a story point estimate for each User Story. One way to do this is by playing Planning Poker.
- The Development Team collectively decide on which User Stories will go into the upcoming Sprint and agree to a Sprint Goal, thus creating a Kanban style Sprint Backlog.