In Scrum, the Sprint starts with Sprint Planning where the Scrum team plans out their work for the Sprint and creates a Sprint Backlog. The Sprint Backlog is the team’s plan to accomplish the work. Sprint planning is timeboxed to 2 hours per week of Sprint, so for a 2-week Sprint it is one event for a maximum of 4 hours, and for a 4-week Sprint, it’s one event for a maximum of 8 hours, and so forth.
To plan the Sprint, the Scrum team considers what is still remaining to do from the Product Backlog, what’s already been done based on the Product Increment that’s been built so far, the progress they have made towards the Product Goal, and the team’s historical performance and current capacity.
In Sprint Planning the team covers 3 topics:
The first topic is about the Why? That is, why is the upcoming Sprint important? What is the Goal of this Sprint? Each Sprint has a Sprint Goal that creates focus for the team and results in a Product Increment that gets the team one step closer to the Product Goal.
The second topic is about the What? Now that the Sprint Goal is clear, the team figures out what cohesive set of Product Backlog Items will help accomplish the Sprint Goal which results in a Product Increment that gets the team one step closer to the Product Goal.
The third topic is about the How? For each Product Backlog Item, the team tasks out the activities needed to complete the item so that the team can accomplish the Sprint Goal which results in a Product Increment that gets the team one step closer to the Product Goal.
The Sprint Goal, the selected Product Backlog Items, and the tasks become the Sprint Backlog. This is the team’s plan to accomplish the work and to deliver on the Sprint Goal.
Parts 1 and 2 are led by the Product Owner with the Developers seeking clarification and providing input. Part 3 is led by the Developers with the Product Owner readily available to answer any remaining questions.
Developers must account for the work needed to accomplish the Sprint Goal as well as all other work that typically happens during the Sprint, like Product Backlog Refinement, continuous improvement initiatives, retrospective action items, technical debt, holidays, vacations, training, etc. In addition, Developers need to account for impediments and distractions like bugs, production issues, all hands-meeting, supporting other teams, and so forth. Developers consider their historical capacity and then assess whether the work is feasible. If not, the Developers negotiate with the Product Owner to reduce the scope while still achieving the goal. Finally, the Developers make a commitment to each other on accomplishing the Sprint Goal.
And that’s Sprint Planning, the 1st event of every Sprint in Scrum. It’s a timeboxed event for the Scrum team to create the plan for accomplishing the work taking into account what still needs to be built based on the Product Backlog, what has already been built based on the Product Increment, the direction the team is heading in based on the Product Goal, and the team’s historical performance and current capacity. It’s 3 topics of why? what? And how? To create a Sprint Backlog that consists of the Sprint Goal, the Product Backlog Items, and the tasks that will help deliver on the Sprint Goal that will result in a product increment that gets them closer to the overall Product Goal.
For more details, sign up for an upcoming foundational Certified Scrum Developer® (CSD®) class, or a Certified Product Owner® (CSPO®) class, or ScrumMaster® (CSM®) class.
