Sprint Planning
Description
This is a meeting attended by the Product Owner and the developers; other individuals invited by the team may also participate. The Scrum Master helps ensure that the meeting is productive and stays within its maximum duration.
It can last up to a full working day, depending on the volume or complexity of the Product Backlog items (user stories) to be included in the next increment.
The meeting must answer three questions:
1.- Why is this sprint valuable?
The Product Owner explains how the product can increase its value with the result of the upcoming sprint. This question determines the Sprint Goal.
2.- What can be done in the sprint?
Once the increase in value expected by the Product Owner has been shared, the developers determine which Product Backlog items they will carry out. During this process, backlog items may be refined if they need further detail or explanation.
3.- How will the selected work be carried out?
The developers decide how to transform the selected items into a finished increment and create the sprint backlog. They may break down each item into tasks lasting one day or less—an approach recommended for less experienced teams. This helps them develop a better intuition for what different types of user stories entail and allows them to visualize the sprint's progress on a day-to-day basis.
Structure
It is recommended to structure the meeting in two parts of similar length, separated by a break:
- What will be delivered at the end of the sprint.
- How the increment will be achieved, estimating the necessary requirements with story points or however the team sees fit.
First half: Why is this sprint valuable and what can be done in it?
The Product Owner is responsible for the presentation in this first half of the meeting.
- They present the highest-priority user stories, explaining what is needed and what they expect can be developed in the next sprint.
- If the backlog has changed significantly since the previous meeting, they explain the reasons behind those changes. The goal is for everyone to understand, in sufficient detail, the increment the sprint is intended to deliver.
- The presentation should be open to questions, and clarifications may be requested. Any developer can put forward suggestions, changes, and alternative solutions, and modify the backlog accordingly.
- This meeting is a key moment in Scrum for encouraging the cross-pollination of ideas and adding value to the product vision.
- After reordering and reconsidering the stories in the backlog, the team defines the "Sprint Goal": a sentence that sums up the value that will be delivered to the customer. Crafting this statement together during the meeting ensures that the whole team understands and shares the purpose of the work.
Second half: how will the increment be achieved?
This second part should be considered a "team meeting", in which all developers must be present and they themselves break down, estimate, and assign the work.
The Product Owner's role is to answer questions and check that the developers understand and share their goal.
- The team builds the Sprint Backlog and breaks down the stories that need a greater level of detail into smaller units.
- The priority stories or tasks for the first few days are established.
- Once this is done, the developers self-assign responsibility for the tasks that best fit their profile, following the order of priority and striving to distribute the work evenly.
Sprint planning in teams with AI
In a team working with AI, planning involves an additional decision: how to distribute sprint tasks between humans and AI. This is not a technical issue, but rather a matter of self-management.
- The sprint goal gains importance. When AI makes it possible to produce almost anything rapidly, the risk of losing focus increases. A clear sprint goal helps in deciding what *not* to do, even when it *could* be done.
- Review is factored into planning. AI can generate in minutes what might take a person hours to verify. Review capacity is just as critical to planning as production capacity; consequently, review and integration tasks are included in the sprint backlog.
Preconditions
The organization has identified and allocated the resources needed to carry out the sprint.
- The highest-priority user stories in the Product Backlog are already "ready", with a sufficient level of specificity and a prior estimate of the work they require.
- The developers have sufficient knowledge of the technologies used and of the product's business to make estimates and to understand the business concepts presented by the Product Owner.
Inputs
- Product Backlog.
- Product developed in previous increments (except in sprint 0).
- Team velocity or throughput in the last sprint, as a basis for estimating the amount of work.
- The customer's business circumstances and the technological environment used, and the value the Product Owner expects to obtain.
Outputs
Common mistake
Planning without prior refinement. If the stories are not sufficiently ready before the meeting (lacking acceptance criteria, with unresolved dependencies, or of unknown size), Sprint Planning turns into a refinement and estimation session that consumes all the available time without producing a realistic commitment. Prior refinement is a precondition for planning, not an alternative to it.
Resources
📊 Scrum Master 5.0Free download · Scrum Manager
📄 Product Owner v.2.0Free download (in Spanish) · Scrum Manager
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.