Sprint Planning Template
A sprint planning template for dev teams and agencies running agile projects. Covers sprint goals, team capacity, backlog selection, dependencies, and includes a 15-minute planning meeting agenda. Whether you're running formal Scrum or just organizing two-week cycles, this template keeps your sprints focused.
What You'll Get
- Sprint overview section — Sprint number, goal, dates, and team members
- Capacity planning table — Available hours per team member with PTO and meeting overhead
- Sprint backlog — Selected items with estimates, assignees, and priorities
- Dependencies and risks — What could block the sprint and how to mitigate
- 15-minute meeting agenda — A structured format to keep planning meetings focused
Download the Template
Get the sprint planning template in PDF format.
No email required. Free to use and share.
Sprint Planning Template Preview
| Team Member | Total Days | PTO / Leave | Meetings / Overhead | Available Hours |
|---|---|---|---|---|
| Alex (Frontend) | 10 | 0 | 2 | 48 hrs |
| Sam (Backend) | 10 | 1 | 2 | 42 hrs |
| Jordan (Design) | 10 | 2 | 1.5 | 39 hrs |
| Total team capacity | 129 hrs | |||
| Item | Assignee | Estimate | Priority |
|---|---|---|---|
| Onboarding wizard UI | Alex | 16 hrs | High |
| Onboarding API endpoints | Sam | 20 hrs | High |
| Welcome email sequence | Jordan | 8 hrs | Medium |
| Progress tracking dashboard | Alex | 12 hrs | Medium |
| Integration tests | Sam | 10 hrs | Medium |
| Help tooltips and docs | Jordan | 6 hrs | Low |
| Total committed | 72 hrs | of 129 hrs capacity | |
- •API endpoints needed before UI integration — Sam to complete by end of Week 1
- •Design review required before frontend work — Jordan to deliver mockups by Day 3
- •Email service integration — Requires third-party API key (requested, ETA Day 2)
Sprint Planning Meeting Agenda (15 Minutes)
Sprint planning doesn't need to be a two-hour ceremony. Here's a focused agenda that keeps the meeting tight:
Review sprint goal
What's the one thing this sprint must accomplish? State it in one sentence. If you can't, the goal isn't clear enough.
Check team capacity
Go around the table: PTO? Appointments? Other commitments? Calculate actual available hours.
Select and estimate backlog items
Pull items from the backlog in priority order. Assign owners and confirm estimates. Stop when you hit 70–80% of capacity (leave buffer for unknowns).
Identify dependencies and risks
What could block us? Who depends on whose work? Flag external dependencies (APIs, approvals, assets).
Confirm and commit
Does the team believe this sprint is achievable? Final gut check. If not, cut scope now.
How to Run a Sprint Planning Meeting
The biggest mistake teams make in sprint planning is treating it as a requirements meeting. Sprint planning isn't about defining what needs to be built—that happens in backlog grooming. Sprint planning is about committing to what will get done in the next cycle based on available capacity.
Come in with a groomed, prioritized backlog. The meeting is about selecting items, confirming estimates, and identifying risks—not debating priorities or writing user stories.
Sprint Planning vs Sprint Grooming
Sprint Planning
Happens at the start of each sprint. Focuses on what the team will commit to delivering.
- • Select items from groomed backlog
- • Confirm estimates and capacity
- • Assign owners
- • Identify sprint-specific risks
- • 15–30 minutes
Sprint Grooming (Backlog Refinement)
Happens during the sprint (usually mid-sprint). Prepares items for the next sprint.
- • Write and clarify user stories
- • Break down large items
- • Add acceptance criteria
- • Rough estimation
- • 30–60 minutes
How to Estimate Sprint Capacity
Capacity planning prevents over-commitment. Here's the formula:
Run Sprints in Corcava
- Kanban boards for sprint backlogs — Drag tasks through To Do, In Progress, Review, Done
- Time tracking per task — See actual hours vs estimates for every item
- Sprint velocity reporting — Track points or hours completed across sprints
- Team workload view — See who's overloaded and who has capacity at a glance
Maps to: Projects, Kanban, Time Tracking, Team Management
Predictable sprints = predictable delivery.See how sprint delivery fits into the full profitability lifecycle →
Frequently Asked Questions
What is sprint planning?
Sprint planning is the meeting at the start of each sprint where the team selects work from the backlog, confirms estimates, assigns owners, and commits to a sprint goal. It answers: "What will we deliver in the next two weeks and do we have the capacity to do it?"
How long should sprint planning take?
For a two-week sprint, 15-30 minutes is sufficient if the backlog is well-groomed. If sprint planning regularly takes more than an hour, the problem is usually poor backlog preparation, not the planning process itself.
What is the difference between sprint planning and sprint grooming?
Sprint grooming (backlog refinement) happens during the current sprint and prepares items for future sprints—writing stories, breaking down work, adding acceptance criteria. Sprint planning happens at the start of the sprint and focuses on selecting and committing to ready items from the groomed backlog.
How do I estimate sprint capacity?
Start with working days per team member, subtract PTO and holidays, subtract meeting overhead (typically 20%), then apply a focus factor of 0.7-0.8 to account for context switching and unexpected work. For a 10-day sprint, a developer typically has 40-48 productive hours available.
Should we use story points or hours for estimation?
Either works. Story points abstract away individual speed differences and focus on relative complexity. Hours are more intuitive and directly map to billing. For agencies that bill hourly, hours make more sense. For product teams, story points work well. The key is consistency—pick one and stick with it.
What happens when a sprint fails?
Sprint failures happen. Don't carry incomplete work forward automatically—re-prioritize it in the next sprint planning. Use the retrospective to understand why: was the scope too ambitious, were there unexpected blockers, or did priorities change mid-sprint? The goal is to improve estimation accuracy over time.