Sprint Planning Meeting Agenda: A Template for Agile Teams
A good sprint planning agenda covers backlog review, sprint goal, story selection, and task breakdown. Here's a reusable template with time blocks and facilitation tips.
Sprint planning is the meeting that kicks off each sprint. A clear agenda makes it run in under two hours. No agenda, and it turns into a four-hour debate about story points.
This post covers a complete sprint planning meeting agenda you can use directly, with time estimates for each section and facilitation tips for common problems.
How Long Should Sprint Planning Take?
The Scrum Guide recommends no more than eight hours for a one-month sprint. In practice:
- Two-week sprint - 1.5 to 2 hours
- One-week sprint - 45 to 90 minutes
- One-month sprint - up to 4 hours
If your sprint planning consistently runs over, the problem is usually that the backlog isn’t groomed before the meeting. Stories that haven’t been refined turn sprint planning into the first time anyone actually thinks through the work.
Sprint Planning Meeting Agenda Template
Before the Meeting (PM)
Time: Day before sprint planning
The PM prepares the backlog before the team assembles:
- Confirm the sprint goal or draft a proposed one
- Order the top of the backlog by priority
- Verify that the top 10-15 stories are groomed (acceptance criteria written, estimated or ready to estimate)
- Remove or archive stale items from the backlog
- Pull velocity data from the last 2-3 sprints
- Identify any external dependencies, holidays, or reduced capacity in the upcoming sprint
- Share any relevant context the team should know going in (new customer feedback, changed priorities, unblocked dependencies)
If the backlog isn’t ready, push the meeting. Sprint planning with an ungroomed backlog is a waste of everyone’s time.
Part 1: Sprint Context and Goal (15-20 minutes)
Who leads: Product Manager
Open by setting context - not reviewing last sprint (that’s the retrospective), but framing what the team is trying to accomplish in this sprint.
Agenda items:
- Recap of current priorities and any changes since the last sprint
- Proposed sprint goal - one sentence that summarizes the value the team will deliver
- Capacity check - who is out this sprint? Any holidays, on-call rotations, or planned leave?
- Team alignment on goal - does the team agree the sprint goal is the right focus?
Sprint goal format:
By the end of this sprint, we will [deliver X] so that [users/business can Y].
Examples:
- “By the end of this sprint, we will launch the onboarding checklist so that new users reach their first activation milestone faster.”
- “By the end of this sprint, we will resolve the three top-reported billing bugs so that support ticket volume drops.”
Facilitation tip: If the team doesn’t agree with the sprint goal, that’s a signal - surface the disagreement now rather than halfway through the sprint.
Part 2: Backlog Review and Story Selection (45-60 minutes)
Who leads: Product Manager with team input
Walk through the groomed backlog items and the team selects what to pull into the sprint based on:
- Alignment with sprint goal
- Team capacity (velocity)
- Story estimates
For each story:
- PM gives a one-sentence summary of the story and why it’s prioritized
- Team confirms they understand and agree with acceptance criteria
- If not estimated, estimate now using planning poker or team consensus
- Pull it in or defer, based on capacity
Velocity guidance: Use the average velocity from the last 2-3 sprints as a starting point. Don’t try to max it out - leave 10-15% buffer for unplanned work, bugs, and interruptions.
Facilitation tip: If estimation is taking too long on a single story, it usually means the story isn’t well-understood. Time-box the discussion to 5 minutes, then either break the story down or defer it.
What to do when the team disagrees on estimates:
- Ask the person with the high estimate what risk or complexity they see that others don’t
- Ask the person with the low estimate what simplification they’re assuming
- Surface the disagreement, align on the right assumption, re-vote
Part 3: Task Breakdown and Ownership (20-30 minutes)
Who leads: Engineering lead with team
Once the sprint backlog is set, break each story into tasks:
- What are the individual technical tasks to complete this story?
- Are there dependencies between tasks?
- Who takes ownership of each task?
- Are there any blockers to starting?
Not every team does this in sprint planning - some teams prefer to break down tasks asynchronously or in daily standups. Either approach works if the team is disciplined about it. The risk of skipping it in sprint planning is that blockers surface later, when there’s less time to respond.
Facilitation tip: Don’t let task breakdown turn into a design session. If the implementation approach is uncertain, flag it and time-box a follow-up spike.
Part 4: Sprint Commitment (5-10 minutes)
Who leads: Scrum Master or PM
Close the meeting with explicit alignment:
- Read the sprint goal out loud
- Confirm the sprint backlog - what is in, what is out
- Check for any last concerns or blockers
- Confirm start date, end date, and review/demo date
Questions to close with:
- “Is there anything in the sprint backlog that feels unclear or risky?”
- “Do we all feel confident we can achieve the sprint goal?”
- “Is there anything outside the sprint backlog that might pull focus this sprint?”
Facilitation tip: If someone says they’re not confident about the sprint commitment, take it seriously. Either reduce scope or address the concern before the meeting ends.
Full Agenda at a Glance
| Section | Time | Owner |
|---|---|---|
| Sprint Context and Goal | 15-20 min | PM |
| Backlog Review and Selection | 45-60 min | PM + Team |
| Task Breakdown and Ownership | 20-30 min | Engineering |
| Sprint Commitment | 5-10 min | Scrum Master / PM |
| Total | 85-120 min |
For a one-week sprint, compress each section by about half.
Common Sprint Planning Problems (and Fixes)
Sprint planning runs 3-4 hours Root cause: the backlog wasn’t groomed. Hold a dedicated backlog refinement session mid-sprint so stories are ready before planning begins.
The team constantly misses the sprint commitment Root cause: overcommitment or poor estimates. Run 2-3 sprints at 80% of historical velocity and track how it goes. Accuracy is more valuable than ambition.
No one agrees on the sprint goal Root cause: misalignment on priorities, often between PM and stakeholders. The sprint planning meeting is too late to resolve this. Hold a pre-planning sync with stakeholders the day before.
Engineering has questions mid-sprint that should have been in planning Root cause: acceptance criteria were unclear or missing. Make passing a “ready checklist” (acceptance criteria written, estimated, dependencies flagged) a requirement before a story can enter sprint planning.
Sprint planning is just a ticket assignment exercise Root cause: no sprint goal, no shared context. If the meeting is just “PM assigns stories to engineers,” it’s not sprint planning - it’s a task assignment meeting. Start with the goal, not the tickets.
What Goes on the Sprint Planning Agenda vs What Doesn’t
Does belong in sprint planning:
- Sprint goal alignment
- Story clarification and acceptance criteria questions
- Estimating unestimated stories
- Capacity discussion and scope decisions
- High-level task breakdown
Doesn’t belong in sprint planning:
- Retrospective items from the last sprint (that’s the retro)
- Detailed technical architecture design (do a spike or separate session)
- Stakeholder status updates
- Bug triage that isn’t sprint-relevant
- Long debates about stories that aren’t in the top of the backlog
Automating Sprint Planning Prep
The most time-consuming part of sprint planning preparation is gathering context: what did the team discuss in meetings last sprint? What customer feedback should shift priority? What stories got stuck and why?
Telos handles this automatically. It listens to team meetings, monitors Slack conversations, and tracks ticket activity, then surfaces a summary of relevant context before each sprint planning session - what changed, what’s stale, what should move up in priority. Your sprint planning agenda runs faster because the PM shows up with full context, not a vague memory of what was discussed two weeks ago.
For the broader sprint planning picture, read the sprint planning guide. If your backlog needs work before sprint planning can be effective, start with backlog grooming. And for prioritizing what goes into the sprint, see RICE prioritization.
Telos automates sprint planning prep - so your agenda items are already current when the team sits down.