What This Template Is For
Sprint planning is the meeting where your team decides what to build in the next sprint and how to build it. Done well, planning takes 60-90 minutes and produces a clear sprint goal with a realistic commitment. Done poorly, it becomes a 3-hour backlog grooming session that ends with a list nobody believes in.
This template walks you through a four-step process: capacity check, sprint goal, backlog review, and team commitment. For a deeper dive into the meeting itself, see the guide to running sprint planning. It works for teams running Scrum with one- or two-week sprints. If you are choosing between Scrum sprints and Kanban flow, the Scrum vs. Kanban comparison breaks down when each works best.
When to Use This Template
- Start of every sprint: Run planning on the first day, before any work begins.
- After a major scope change: If priorities shifted since last sprint, re-align.
- New team kickoff: Establish the planning ritual from sprint one.
- When commitments keep missing: Identify whether the issue is overcommitment, unclear goals, or poor estimation.
Step-by-Step Instructions
Step 1: Check Team Capacity (10 minutes)
Before pulling anything into the sprint, calculate how much work the team can actually take on. Account for PTO, on-call rotations, meetings, and any carry-over work from the previous sprint.
- ☐ List each team member and their available days this sprint
- ☐ Subtract planned time off, on-call duties, and recurring meetings
- ☐ Calculate total available story points based on recent velocity
- ☐ Note any carry-over items from last sprint
Step 2: Define the Sprint Goal (10 minutes)
Write one clear sentence describing what the team will accomplish. A good sprint goal is outcome-oriented, not a feature list.
- ☐ Sprint goal stated in one sentence tied to a product or team OKR
- ☐ Goal is achievable given capacity from Step 1
- ☐ Team agrees the goal is the right priority
Step 3: Review and Select Backlog Items (30 minutes)
The product manager presents the top-priority user stories from the backlog. For each candidate item:
- ☐ Is the story well-defined with clear acceptance criteria?
- ☐ Has it been estimated (story points or t-shirt size)?
- ☐ Are there dependencies on other teams or systems?
- ☐ Does it contribute to the sprint goal?
Pull items into the sprint until you reach capacity. Resist the urge to squeeze in "just one more."
Step 4: Commit as a Team (10 minutes)
The team reviews the full sprint scope and explicitly commits. This is not the PM telling the team what to do. It is the team agreeing they can deliver.
- ☐ Team reviews the full list of sprint items
- ☐ Total story points are within velocity range
- ☐ Each item has an owner or pair assigned
- ☐ Team verbally commits to the sprint goal
The Sprint Planning Template
Sprint: [Sprint number]
Dates: [Start date]. [End date]
Sprint Goal: [One sentence]
Facilitator: [Name]
Capacity
| Team Member | Available Days | Notes |
|---|---|---|
| [Name] | [X of Y days] | [PTO, on-call, etc.] |
| [Name] | [X of Y days] | |
| [Name] | [X of Y days] |
Total capacity: [X] story points (based on velocity average of last 3 sprints: [Y])
Sprint Backlog
| # | User Story | Points | Owner | Status |
|---|---|---|---|---|
| 1 | [Story title] | [Pts] | [Name] | Not Started |
| 2 | [Story title] | [Pts] | [Name] | Not Started |
| 3 | [Story title] | [Pts] | [Name] | Not Started |
| 4 | [Story title] | [Pts] | [Name] | Carry-over |
Total committed: [X] points
Buffer: [Y] points reserved for bugs / unplanned work
Risks and Dependencies
| Risk / Dependency | Impact | Mitigation |
|---|---|---|
| [Describe] | [High / Med / Low] | [Plan] |
Example
Sprint: Sprint 22 | Dates: Feb 10. Feb 21
Sprint Goal: Users can filter and export their activity history, reducing support tickets about missing data.
| Team Member | Available Days | Notes |
|---|---|---|
| Alex (PM) | 10 of 10 | |
| Dana (Eng) | 8 of 10 | PTO Feb 14-15 |
| Raj (Eng) | 10 of 10 | |
| Kim (Design) | 9 of 10 | On-call Feb 17 |
Total capacity: 34 story points (velocity average: 36)
| # | User Story | Points | Owner | Status |
|---|---|---|---|---|
| 1 | Add date range filter to activity feed | 8 | Raj | Not Started |
| 2 | Add CSV export button to activity page | 5 | Dana | Not Started |
| 3 | Show empty state when no activity matches filter | 3 | Kim + Dana | Not Started |
| 4 | Fix timezone bug in activity timestamps | 3 | Raj | Carry-over |
Total committed: 19 points | Buffer: 15 points for bugs and unplanned work
Tips
- Keep planning under 90 minutes. If planning runs long, stories are not refined enough. Move estimation to a separate grooming session mid-sprint.
- Leave a buffer. Plan to 70-80% of your velocity. Every sprint has unplanned work. A team that commits to 100% of capacity will miss every sprint.
- Write the sprint goal before selecting stories. The goal drives story selection, not the other way around.
- Track carry-over explicitly. If a story carries over twice, it is either too large (split it), blocked (escalate), or not a real priority (remove it from the backlog).
- Involve the whole team. Engineers, designers, and QA should all be in planning. The PM proposes priorities. The team decides what fits. That is the foundation of agile delivery.