An example of a sprint planning meeting agenda for a product team must separate the two-part sprint planning structure — the "what" conversation (which backlog items to commit to) from the "how" conversation (how engineering will build them) — because conflating these in a single agenda consistently produces overcommitted sprints where stories get pulled in before the technical approach is understood.
Sprint planning is the single most important product-engineering alignment meeting of each sprint cycle. Run well, it produces a realistic commitment with shared understanding. Run poorly, it produces an optimistic list that engineering never believed in, followed by a sprint review where half the stories are incomplete.
Sprint Planning Meeting Agenda Template
H3: Pre-Meeting Preparation (PM owned)
Before the meeting:
- [ ] Top 10-15 backlog items are groomed, estimated, and acceptance-criteria-complete
- [ ] Team capacity is calculated: (sprint days × team members × availability %) - PTO - ceremonies
- [ ] Carryover from previous sprint is accounted for in capacity calculation
- [ ] Sprint goal is drafted (1-2 sentence statement of what success looks like)
H3: Part 1 — Sprint Goal and What (30 minutes)
[0-5 min] Sprint review recap
- What did we complete in the last sprint?
- What carried over and why?
- Any learnings that affect this sprint's priorities?
[5-15 min] Sprint goal presentation
- PM presents the proposed sprint goal
- Team aligns on whether the goal is achievable given capacity
- Goal is refined if needed
[15-30 min] Story selection
- PM walks through top priority stories
- Team confirms understanding of each story before committing
- Stories are added to sprint until capacity is reached
- Rule: Do not add a story to the sprint if there are unresolved questions about scope or acceptance criteria
H3: Part 2 — How (30-60 minutes, engineering-led)
[0-30 min] Technical design for complex stories
- Engineering lead walks through approach for highest-complexity stories
- Dependencies identified and owners assigned
- If a story requires more design work before it can be built, move it to the next sprint rather than committing without a plan
[30-60 min] Task breakdown (optional for some teams)
- Each committed story broken into engineering tasks
- Task-level estimates verified against story-level estimates
- Any gaps between story estimate and task breakdown are resolved now
H3: Sprint Planning Commitment
End of meeting:
- Sprint goal confirmed by PM and engineering lead
- Committed story list reviewed and agreed
- Any stories pulled due to capacity or complexity concerns are noted
- Next sprint planning date confirmed
Sprint Planning Anti-Patterns
H3: What Breaks Sprint Planning
- Grooming stories in sprint planning: If stories need grooming, stop and move them to the backlog. Don't groom in planning.
- Adding stories after capacity is reached: "Just one more small story" is how you create a 120% sprint. Respect the capacity calculation.
- PM not attending Part 2: The PM should be available during the technical design phase to answer questions about scope and acceptance criteria.
- No sprint goal: A sprint without a goal is a list of tasks, not a sprint. The goal is what unifies the work and guides trade-off decisions when time pressure hits.
FAQ
Q: How long should sprint planning take for a 2-week sprint? A: 1-2 hours total. Part 1 (what) takes 30-45 minutes. Part 2 (how) takes 30-60 minutes depending on story complexity. Sprint planning that regularly exceeds 2 hours indicates insufficient pre-planning or stories that aren't ready to be sprinted.
Q: Who should attend sprint planning? A: The PM, the full engineering team, the design lead (if UI work is in scope), and the QA lead (if QA planning is part of sprint planning). Stakeholders should not attend sprint planning — it's an execution meeting, not a stakeholder alignment meeting.
Q: How do you calculate team capacity for sprint planning? A: Sprint days multiplied by team members multiplied by availability factor (typically 70-80% to account for meetings, code reviews, and unplanned work) minus any PTO. Express capacity in story points or ideal developer days, whichever your team uses.
Q: What happens when the sprint backlog exceeds capacity? A: Remove stories from the sprint, lowest priority first. Never expand capacity to fit more stories — you're setting the team up for incomplete sprints and morale damage when they can't hit commitments.
Q: How do you write a good sprint goal? A: One or two sentences describing what the team is trying to achieve for the customer or business this sprint — not a list of features. Example: "Enable enterprise admins to identify and manage inactive licenses so they can prepare for renewal audits without manual spreadsheet work."
HowTo: Run a Sprint Planning Meeting for a Product Team
- Complete pre-meeting preparation: groom top 10-15 stories to acceptance-criteria-complete, calculate team capacity, and draft the sprint goal
- Run Part 1 starting with a sprint review recap, then sprint goal alignment, then story selection up to capacity
- Do not add any story to the sprint if there are unresolved scope or acceptance criteria questions — move it to the backlog for the next sprint
- Run Part 2 with the engineering lead walking through technical approach for complex stories and identifying dependencies before committing
- End the meeting with a confirmed sprint goal, committed story list, and any stories pulled noted with their reason for deferral
- Enforce the capacity limit strictly — never add stories after capacity is reached, even small ones