What is Sprint Planning?

Sprint Planning is held before the Sprint begins. The purpose of this meeting is to define the Sprint plan and set the Sprint Goal.

Sprint Planning involves agreeing on the number of backlog items to be completed in the Sprint, which is the responsibility of the development team, and defining the goal for the current Sprint and the Sprint Backlog.

During the Sprint Planning meeting, the Product Owner presents the highest-priority features to the entire team. Then, they discuss which user stories the team will work on during this Sprint. The entire team should attend. If additional expertise is needed for specific backlog items, stakeholders may also be invited. The meeting can also include a refinement session.

Sprint Planning

Benefits of Sprint Planning Meeting

Here are some benefits of running a successful Sprint Planning meeting:

• Helps the team align on the Sprint goal and commitment.
• Enables task discovery, registration, prioritization, and estimation.
• Creates a platform to communicate dependencies and assess team capacity to set and commit to achievable Sprint goals.

Duration of Sprint Planning Meeting

Each Sprint begins with a Sprint Planning meeting. Typically, for a 4-week Sprint, this meeting should last 8 hours. For a 2-week Sprint, it should last about 4 hours. As a general rule of thumb, multiply the number of weeks in the Sprint by two hours to determine the total Sprint Planning meeting duration. The table below illustrates this rule.

Preparation Before the Meeting

Now, let’s review what each Scrum role needs to prepare before attending the Sprint Planning meeting:

For Scrum Master

• Identify the right participants and arrange logistics such as WebEx, video conferencing, etc.
• Prepare and distribute the agenda.
• Ensure team members’ skills and capabilities are known and aligned with the requirements of the Sprint backlog items.

For Product Owner

• Each feature or user story should be small enough to be completed within a Sprint and include detailed requirements and acceptance criteria.
• Ensure the backlog is prioritized with the most important items at the top and meets the team’s Definition of Ready.

For Development Team

• Update the team’s Definition of Done if needed, and keep it ready for reference during the meeting.

Sprint Planning Meeting (Part 1 and Part 2)

This meeting is split into two parts. In the first session, the Product Owner reviews the feature list and defines what needs to be built in the next Sprint. The second session involves identifying the tasks required to complete the work. The Sprint Planning meeting should result in a Sprint Goal and a Sprint Backlog.

Sprint Planning Parts

Sprint Planning Meeting – Part 1

Part 1 of the Sprint Planning meeting is a review of the Product Backlog items the Product Owner wants the team to forecast and deliver in the next Sprint. This is the time when the Product Owner describes what she wants to deliver by the end of the next Sprint. During this phase, it is common for the team to ask clarifying questions and resolve ambiguities. At the end of Part 1, the team will select a Sprint Goal — a single sentence describing the overall outcome of the Sprint. This helps answer questions about depth and breadth later: if work isn’t directly aligned with the Sprint Goal, it won’t be completed during the Sprint. Key activities in the first part of Sprint Planning include:

• The Product Owner presents the highest-priority items from the Product Backlog to the team.
• Define the Sprint Goal — the Product Owner collaborates with the Development Team to determine the Sprint Goal.
• The team and Product Owner work together to identify which features can be delivered in the upcoming Sprint.
• The team commits to this selected Product Backlog at the end of the session.

Sprint Planning Meeting – Part 2

In Part 2 of the Sprint Planning meeting, the team decides how to build the work. During this session, the team begins breaking down Product Backlog items into tasks and estimating them, typically within hours. The Product Owner must be available during this session but does not need to be physically present. In fact, many teams find it helpful to have the Product Owner absent during this detailed discussion. Knowing the Product Owner is available but not observing the conversation about implementation options allows teams to explore freely without fear of misunderstanding or panic. If the Product Owner remains in the room, the Scrum Master must manage this part of the meeting, keeping the team focused and free to explore possibilities without being influenced by the Product Owner’s opinions. Key activities in Part 2 include:

• The team plans how to fulfill the commitment, detailing the work to be included in the Sprint Backlog.
  • Detailed Planning – Break down user stories into tasks. Ensure the team divides the story into tasks, as this allows them to consider everything needed to complete the story. It’s also a good practice to treat testing as a separate task.
  • Estimating Stories – The team can use techniques like Planning Poker or T-shirt sizing to estimate the effort of each story. Team members register their chosen work and estimate how long each task will take to complete.