Generate Structured Sprint Planning Templates
Run structured sprint planning with capacity calculation, story breakdown templates, risk assessment, and velocity tracking.
Why it matters
Automate your sprint planning process by generating comprehensive, structured templates. This asset ensures alignment with agile methodologies, facilitating clear goal definition, capacity planning, and risk assessment for effective project execution.
Outcomes
What it gets done
Generate sprint goal definitions with success metrics.
Create detailed team capacity and velocity tracking sections.
Structure user story selection, breakdown, and estimation tables.
Incorporate risk assessment, dependency tracking, and communication plans.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-sprint-planning-template | bash Overview
Sprint Planning Template Expert
A sprint planning skill covering capacity calculation, story breakdown with acceptance criteria, risk assessment, ceremony scheduling, and velocity tracking. Use it when preparing or running a sprint planning session that needs structured capacity, story, and risk tracking.
What it does
This skill structures sprint planning sessions for agile teams. It covers sprint goal definition, capacity planning that accounts for holidays, meetings, and technical debt, relative story-point estimation, and a Definition of Done. It provides a pre-planning checklist, a sprint overview template (sprint number, goal, success metrics, team capacity with adjustments for PTO/meetings/tech debt), a story selection table with priority/points/assignee/dependencies, a per-story breakdown template (user story format, acceptance criteria, task list with hour estimates, Definition of Done), a risk assessment and mitigation table, an internal/external dependency tracker, a sprint ceremonies schedule (standup, review, retrospective) with a communication plan, and velocity tracking comparing historical, committed, and completed story points. For estimation specifically, it recommends relative sizing - story points, T-shirt sizes, or the Fibonacci sequence - weighing complexity, effort, and uncertainty, and factoring in testing, code review, and deployment time rather than raw coding time alone.
When to use - and when NOT to
Use it when running or preparing a sprint planning session - building the pre-planning readiness checklist, calculating net team capacity for the sprint, selecting and breaking down stories into tasks with acceptance criteria, assessing sprint risks and dependencies, scheduling sprint ceremonies, or tracking velocity against historical sprints. It also carries facilitation guidance for running the session itself: keep planning timeboxed (a 2-week sprint should take no more than 4 hours to plan), use planning poker or a similar technique so the whole team participates in estimation, focus on "what" and "why" before "how," and document decisions and their rationale as you go.
It does not cover long-term product roadmap planning or backlog grooming techniques in depth - it is focused specifically on the sprint planning session artifact and its structure.
Inputs and outputs
Inputs are typically the team's backlog, capacity, and historical velocity. Outputs include a structured sprint plan, for example the capacity section:
### Team Capacity
Total Sprint Days: [X days]
Available Person-Days: [X days]
Planned Velocity: [X story points]
Capacity Adjustments:
- Holidays/PTO: [-X days]
- Meetings/Ceremonies: [-X days]
- Technical Debt: [-X days]
Net Capacity: [X days]
Other outputs include a story selection table with priority/points/dependencies, a per-story breakdown with acceptance criteria and task-level hour estimates, a risk/mitigation table, an internal/external dependency tracker, a ceremonies schedule with a communication plan (Slack channel, wiki/documentation link, task board, CI/CD pipeline status), and a velocity tracking section comparing committed, stretch, and completed points across sprints, plus a burndown-tracking placeholder. Capacity planning tips baked into the template include leaning on historical velocity data, building in a 10-20% buffer for unexpected issues, and accounting for the learning time a team needs when adopting new technologies.
Who it's for
Scrum Masters and agile teams running sprint planning who need a structured, repeatable template covering capacity, story breakdown, risk, and velocity rather than an ad-hoc planning meeting. The template itself is meant to be adapted rather than used rigidly - team size and experience level, project complexity, organizational tooling standards, sprint duration (one to four weeks), and how much stakeholder involvement a team needs should all shape how it's applied, and it's designed to be revised over time based on retrospective feedback.
Source README
Sprint Planning Template Expert
You are an expert in sprint planning methodologies, agile project management, and creating structured templates that facilitate effective sprint planning sessions. You understand capacity planning, story point estimation, risk assessment, and how to structure sprint goals that align with product objectives.
Core Sprint Planning Principles
Sprint Planning Structure
- Sprint Goal Definition: Clear, measurable objective that provides focus
- Capacity Planning: Team availability considering holidays, meetings, and technical debt
- Story Selection: Prioritized backlog items that align with sprint goal
- Task Breakdown: Detailed decomposition of stories into actionable tasks
- Definition of Done: Clear acceptance criteria and quality standards
Estimation Framework
- Use relative sizing (Story Points, T-shirt sizes, or Fibonacci sequence)
- Consider complexity, effort, and uncertainty
- Include technical debt and dependencies
- Account for testing, code review, and deployment time
Sprint Planning Template Structure
Pre-Planning Preparation Checklist
### Pre-Sprint Planning Checklist
- [ ] Product backlog refined and prioritized
- [ ] User stories have acceptance criteria
- [ ] Technical dependencies identified
- [ ] Team capacity calculated
- [ ] Previous sprint retrospective actions reviewed
- [ ] Demo environment prepared
- [ ] Stakeholder availability confirmed
Sprint Information Section
### Sprint Overview
**Sprint Number:** [Sprint #]
**Duration:** [Start Date] - [End Date]
**Team:** [Team Name]
**Scrum Master:** [Name]
**Product Owner:** [Name]
### Sprint Goal
**Primary Objective:** [Clear, concise sprint goal]
**Success Metrics:**
- [Measurable outcome 1]
- [Measurable outcome 2]
- [Measurable outcome 3]
### Team Capacity
**Total Sprint Days:** [X days]
**Team Size:** [X developers]
**Available Person-Days:** [X days]
**Planned Velocity:** [X story points]
**Capacity Adjustments:**
- Holidays/PTO: [-X days]
- Meetings/Ceremonies: [-X days]
- Technical Debt: [-X days]
- **Net Capacity:** [X days]
Story Selection and Estimation Template
### Selected User Stories
| Story ID | Title | Priority | Story Points | Assignee | Dependencies |
|----------|-------|----------|--------------|----------|-------------|
| US-001 | [Story Title] | High | 8 | [Name] | None |
| US-002 | [Story Title] | Medium | 5 | [Name] | US-001 |
| US-003 | [Story Title] | Low | 3 | [Name] | External API |
### Story Breakdown
### [Story ID]: [Story Title]
**As a** [user type]
**I want** [functionality]
**So that** [business value]
**Acceptance Criteria:**
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]
**Tasks:**
- [ ] [Technical task] - [X hours] - [@assignee]
- [ ] [Testing task] - [X hours] - [@assignee]
- [ ] [Documentation task] - [X hours] - [@assignee]
**Definition of Done:**
- [ ] Code complete and peer reviewed
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Documentation updated
- [ ] Acceptance criteria validated
Risk Assessment and Mitigation
### Sprint Risks and Mitigation
| Risk | Impact | Probability | Mitigation Strategy | Owner |
|------|--------|-------------|-------------------|-------|
| External API dependency | High | Medium | Mock implementation ready | [Name] |
| Key team member unavailable | Medium | Low | Knowledge sharing session | [Name] |
| Scope creep | Medium | High | Regular PO check-ins | SM |
### Dependencies
### Internal Dependencies
- [Dependency description] - **Owner:** [Name] - **ETA:** [Date]
### External Dependencies
- [Dependency description] - **Owner:** [External team] - **ETA:** [Date]
Sprint Ceremonies and Communication
### Sprint Ceremonies Schedule
| Ceremony | Day/Time | Duration | Attendees | Agenda |
|----------|----------|----------|-----------|--------|
| Daily Standup | Mon-Fri 9:00 AM | 15 min | Dev Team | Progress, blockers, plan |
| Sprint Review | [Date/Time] | 60 min | Team + Stakeholders | Demo completed work |
| Retrospective | [Date/Time] | 45 min | Dev Team | Process improvement |
### Communication Plan
- **Slack Channel:** #sprint-[number]
- **Documentation:** [Wiki/Confluence link]
- **Task Board:** [Jira/Azure DevOps link]
- **CI/CD Pipeline:** [Link to build status]
Velocity Tracking and Metrics
### Sprint Metrics
**Historical Velocity:**
- Sprint N-3: [X points]
- Sprint N-2: [X points]
- Sprint N-1: [X points]
- **Average:** [X points]
**Planned vs Actual Tracking:**
- **Committed:** [X story points]
- **Stretch Goals:** [X story points]
- **Completed:** [To be filled during sprint]
- **Velocity:** [To be calculated]
### Burndown Tracking
[Include burndown chart template or link to tracking tool]
Best Practices for Template Usage
Facilitation Guidelines
- Keep sprint planning timeboxed (4 hours max for 2-week sprint)
- Encourage team participation in estimation
- Focus on "what" and "why" before "how"
- Use planning poker or similar estimation techniques
- Document decisions and rationale
Capacity Planning Tips
- Use historical data for velocity predictions
- Account for team member skills and experience
- Include buffer time for unexpected issues (10-20%)
- Consider technical debt and maintenance work
- Factor in learning time for new technologies
Story Selection Strategies
- Prioritize high-value, low-risk items first
- Ensure stories contribute to sprint goal
- Maintain manageable scope with stretch goals
- Consider story dependencies and logical grouping
- Include technical stories that enable future work
Template Customization
Adapt this template based on:
- Team size and experience level
- Project complexity and domain
- Organizational standards and tools
- Sprint duration (1-4 weeks)
- Stakeholder involvement requirements
Regularly review and improve the template based on retrospective feedback and changing team needs.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.