The template
Four-section structure for a 2.5-hour planning session
The total time below is 2.5 hours, well under the Scrum Guide's 4-hour ceiling for a 2-week sprint. Plan to use the full 2.5 hours; over time, mature teams compress it to 90 minutes as backlog refinement and capacity calculation become routine.
Section 1: Capacity calculation (20 min)
The Scrum Guide does not explicitly call this out as a separate topic, but skipping it is the most common cause of over-commitment. For each developer, calculate available hours (working days in the sprint × 6 hours of focused capacity, the empirical maximum from Microsoft Workplace Analytics research on engineer time-budget), then subtract planned PTO, public holidays, conference attendance, and any committed support time. Sum across the team. If using story points, calibrate against the rolling 3-sprint velocity average rather than the most recent sprint. Capacity numbers below this baseline plus a 15% confidence buffer become the commitment ceiling for the next two sections.
Section 2: Why (sprint goal) (20 min)
The product owner proposes the sprint goal in one outcome-oriented sentence. The team discusses whether the goal is feasible given capacity, valuable given the current product state, and clear enough that mid-sprint trade-offs can be made by reference to it. A good sprint goal lets a developer answer "does this task still make sense?" without checking with the product owner. Lock the goal before moving to backlog selection; selecting items first and reverse-engineering a goal produces incoherent sprints.
Section 3: What (backlog selection) (50 min)
Working down the prioritised backlog, the team pulls items that contribute to the sprint goal until estimated effort approaches the capacity ceiling. For each item, confirm the acceptance criteria, surface any technical risks, and decide whether the item is small enough to commit (Scrum convention: each item should be completable within the sprint, typically meaning under 8 story points or 3 days of work). Items that fail this test go back to refinement, not into the sprint. The temptation to over-commit because "we can always pull more" produces a sprint that finishes nothing fully.
Section 4: How (task breakdown) (50 min)
The development team breaks each selected backlog item into the concrete tasks needed to complete it: design, implementation, test, documentation. Tasks should be small enough to complete in under a day, surfacing any work that previously hid in "everything else." Identify dependencies between tasks and across team members, sequence accordingly. This section is where the team commits to the sprint not just at the item level but at the work level. The Atlassian State of Agile 2024 research found that teams which break work to sub-day task granularity during planning complete 28% more of their committed scope than teams that leave breakdown to mid-sprint.
Close: confirm commitment (10 min)
Read aloud the sprint goal, the committed backlog items, and the total capacity number. Each developer verbally confirms they can execute the plan as scoped. Note any explicit risks (a dependency on another team, an experimental approach, a key person taking PTO mid-sprint). The verbal commitment from each team member matters: research on team accountability (Daniel Coyle, "The Culture Code") shows that aloud-commitments produce materially higher follow-through than silent assent.
Backlog readiness
The single biggest predictor of good planning is refinement done last week
Sprint planning works only if the backlog is ready before the meeting starts. The 2020 Scrum Guide does not mandate a specific refinement cadence, but the practical pattern that works across most Scrum teams is 60 to 90 minutes per week of backlog refinement (often split into two 30-minute sessions) so that the top 8 to 10 items in the backlog are always estimated, acceptance criteria written, and technical questions resolved before any planning meeting.
When refinement is skipped, planning expands to absorb it. A 90-minute planning meeting becomes a 4-hour meeting because the team is doing refinement on the fly. Worse, the items chosen are usually whatever feels familiar rather than what is highest priority, because the team selects from items they understand well, not from items the product owner ranked. The fix is a hard rule: items appear in sprint planning only if they have a definition of ready (typically: clear description, acceptance criteria, technical approach, estimate, dependencies surfaced).
For teams new to refinement discipline, the bootstrapping rule is simple: any item that takes more than 5 minutes to clarify in planning gets moved back to refinement and the team picks something else. This is uncomfortable in the first sprint and stops being a problem by the third.
Related ceremonies
The sprint planning ceremony in context
Daily standup / Daily Scrum
The 15-minute ceremony that keeps the sprint plan on track. Three Scrum questions, time-boxed.
Sprint review
Demo-first format at the end of the sprint. Stakeholder feedback structure that prevents review-as-status-meeting drift.
Sprint retrospective (5 formats)
Start-Stop-Continue, 4Ls, Sailboat, Mad-Sad-Glad, Timeline. Which retro format to pick when.
Generic retrospective
If your retro is for a project rather than a sprint, use the project retro structure here.
FAQ
Common questions about sprint planning
How long should sprint planning be?
The 2020 Scrum Guide caps sprint planning at 8 hours for a 4-week sprint and proportionally less for shorter sprints. For 2-week sprints (the most common length) that means a 4-hour ceiling, with most mature teams running it in 2 to 3 hours. The 4-hour ceiling is the maximum, not the target. Teams running 4-hour sprint plannings for 2-week sprints usually have an unclear backlog or under-prepared product owner.
Who attends sprint planning?
The entire Scrum team: developers, product owner, and Scrum master. The 2020 Scrum Guide explicitly allows the team to invite other people for advice (a designer, an architect, a stakeholder with domain knowledge), but the decision authority sits with the Scrum team. Avoid making sprint planning a stakeholder review meeting; that is what the sprint review at the end of the sprint is for.
What is the sprint goal and why does it matter?
The sprint goal is a single sentence describing what the team commits to achieve during the sprint. The 2020 Scrum Guide added the sprint goal as a required artefact precisely because teams without one drift between unrelated tasks. A good sprint goal is outcome-oriented ('Validate that users will pay for the export feature') rather than activity-oriented ('Build the export feature'). The goal lets the team make trade-offs mid-sprint when reality differs from plan.
How do you calculate sprint capacity?
Available working days per team member, minus planned PTO and holidays, minus expected meeting overhead (typically 20-25%), minus support and bug-fix capacity (typically 15-20% for product teams). The remaining hours or story points are the team's actual sprint capacity. Most teams overestimate capacity by 30 to 40% in their first sprint and need three sprints to calibrate. Track planned versus actual velocity to converge on a realistic number.
What if the backlog isn't ready for planning?
Reschedule planning or shorten the sprint. The Scrum Guide places responsibility on the product owner for backlog readiness, but the practical fix is establishing a refinement cadence: 60-90 minutes per week of backlog refinement so the top 8-10 items are always ready before planning. Sprint planning is not the place to do refinement work; it slows the meeting and produces ill-defined commitments.
Should sprint planning be split into two parts?
The 2020 Scrum Guide consolidated what was previously called 'Part 1' (what to do) and 'Part 2' (how to do it) into a single event with three topics. Many teams still find it useful to break for 15 minutes between selecting the backlog (what) and planning the tasks (how), but they should be one continuous ceremony. Splitting across two days causes context loss and re-litigation of decisions.