💡 The purpose of the Sprint Planning is to plan the work to be performed in the Sprint with the entire Scrum Team.
Sprint Planning is the first meeting that happens at the beginning of the Sprint. Usually on day 1 of a new Sprint before any work has begun.
Maximum duration: 8 hours (for 1 month sprints) as per the Scrum Guide.
Recommended duration: 2 hours for 2 weeks Sprints.
Agenda #
- Discuss and agree on the Sprint Goal.
- Select items from the Product Backlog to be done during this Sprint to achieve the Sprint Goal.
- Decompose the Product Backlog Items (PBIs) into tasks to be accomplished.
- Identify any dependencies on something or someone outside of the team.
- Identify constraints such as days off, other work, unavailability of resources, etc.
- (If used) Estimate the work to be done and plan using past velocity as guidance.
Attendees #
The whole Scrum Team (Developers, Scrum Master, and Product Owner), and any subject matter experts the team has decided to invite.
Who leads the meeting: Each role has a different part of the meeting to lead. The whole team participates together and should not be dependent on one person leading the meeting.
Preparation #
To make the meeting more productive, every participant needs to prepare upfront.
- The Product Owner (PO) needs to have a general idea of what the Sprint Goal should be for the next Sprint.
- Developers need to be aware of the contents of the Product Backlog (PB), so that the team doesn’t waste time during the meeting.
- The team might need to chase some answers from other teams or subject matter experts to understand the work items better.
- Sometimes the team might want to invite subject matter experts into their Sprint Planning. This needs to be arranged in advance.
Example #
- If the Sprint hasn’t been closed yet (e.g. if using tools like Jira), the team may review and confirm that all work items are up to date and close the Sprint.
- The PO starts by showing the current Product Backlog and the top priority items on the list.
- The PO also states the Sprint Goal for the upcoming Sprint. The team discusses if it is achievable.
- If there are some incomplete items that were moved from the past Sprint, the team needs to decide if they want to complete it in the upcoming Sprint or put it on the back burner for now.
- The team then reviews what items they want to pull into the Sprint required to achieve the Sprint Goal, usually starting from the top of the list. This creates their Sprint Backlog.
- The Product Owner provides any additional information on what needs to be done if developers have questions.
- Developers should review each item and discuss what exactly they need to do in order to complete it. They may decompose it into subtasks, add more details to the description, discuss test cases, etc.
- If some items are not estimated (in case the team uses estimation) or some items are in progress from the past Sprint, the team should estimate each work item. This is usually done in story points, but it’s not mandatory.
- The Scrum Master should provide some information on the team’s velocity using past Sprints data.
- The team then reviews how much work they pulled into the Sprint and discusses whether it is doable based on their past velocity. They readjust the Sprint Backlog at this point.
- The Scrum Master asks additional questions about whether the workload is reasonable but also challenging enough, what blockers may prevent the team from completing the work, whether there are holidays or absences planned, etc.
- Once the team feels comfortable with the work they pulled into their Sprint Backlog, they can start the Sprint. This usually means that Developers believe that they can complete the work based on the information they have thus far.
