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:
Sprint Planning Topic 1 – The Why and the Sprint Goal
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 the focus for the team and results in a Product Increment that gets the team one step closer to the Product Goal.
Sprint Planning Topic 2 – The What and the Product Backlog Items or User Stories
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 or user stories will help accomplish the Sprint Goal and produce a Product Increment that gets the team one step closer to the Product Goal.
Sprint Planning Topic 3 – The How and the Tasks
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 and produce a Product Increment that gets the team one step closer to the Product Goal.
The Sprint Backlog
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, deliver on the Sprint Goal, and produce a Product Increment.
The Product Owner leads the team through topics 1 and 2 while the Developers seek clarification and provide input. The Developers lead topic 3 while the Product Owner is 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 company meetings, 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 Sprint Goal. Finally, the Developers commit to each other to accomplish the Sprint Goal.
Sprint Planning Summary
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 and produce a product increment that gets them closer to the overall Product Goal.
For more details, sign up for an upcoming foundational ScrumMaster® (CSM®) class or a Certified Product Owner® (CSPO®) class or Certified Scrum Developer® (CSD®) class.
Next check out the entire Scrum in a Nutshell series:
Scrum in a Nutshell
What is Scrum? Scrum is a framework for developing, delivering, and sustaining complex products. It all starts with our stakeholders, customers, and users, who have an idea about a product they need and want developed. They collaborate directly with Developers to turn this idea into reality. The Product Owner and Developers Developers in Scrum are…
Scrum Accountabilities, Artifacts, and Events in a Nutshell
In Scrum, there are 3 accountabilities, 3 artifacts, 3 commitments, and 5 events. Scrum Accountabilities The 3 accountabilities in Scrum are: Scrum Artifacts The 3 artifacts in Scrum are: Scrum Commitments The Product Goal, Sprint Goal, and Definition of Done are referred to as commitments in Scrum. The Scrum team commits to delivering a Product…
Scrum Team in a Nutshell
The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master. Developers Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing. Cross-functional Developers are cross-functional to remove bottlenecks and…
Product Backlog Refinement in a Nutshell
The Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal. Product Backlog Attributes The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side…
Sprint Planning in a Nutshell
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…
Daily Scrum in a Nutshell
The Daily Scrum is a brief daily planning event by the Developers to inspect their work and progress toward the Sprint Goal that will result in a Product Increment. The Developers created their Sprint plan or Sprint Backlog in Sprint Planning at the beginning of the Sprint. However, this plan is not static. It’s updated…
Sprint Review in a Nutshell
The Sprint Review is a working session for the stakeholders, users, and customers to collaborate with the Scrum team which includes the Developers, Product Owner, and Scrum Master, and inspect the progress made toward the Product Goal based on the latest Product Increment. The Sprint Review is about getting feedback from the stakeholders and users…
Sprint Retrospective in a Nutshell
The Sprint Retrospective is a reflection event that occurs at the end of each Sprint. It is for the entire Scrum team which includes the Product Owner, Developers, and ScrumMaster to inspect how they are operating and then come up with a continuous improvement plan to adapt and become more effective as a team and…
Product Increment and the Definition of Done in a Nutshell
The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and…
Scrum Values in a Nutshell
For teams to succeed with Scrum, team members must become proficient in living the 5 Scrum values of commitment, focus, openness, respect, and courage. Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal. Focus:…
Scrum Foundations and Theory in a Nutshell
Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses…
Scrum and the Manifesto for Agile Software Development
Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products. The participants shared and learned about…