Sprint Planning
Kick off a sprint with goals, capacity-adjusted scope, P0 vs stretch, and a written sprint plan (optionally synced via project tracker connectors).
Overview
Sprint Planning is an agent skill most often used in Build (also Operate) that drafts sprint goals, capacity-aware scope, and a sprint plan document when kicking off a new iteration.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill sprint-planningWhat is this skill?
- Standalone flow: goals, capacity (PTO/meetings), backlog scope, dependencies/risks, sprint plan doc
- Supercharged path: project tracker backlog pull, sprint creation, assignments; calendar for availability
- Usage: /sprint-planning with sprint name or date range argument hint
- Handles carryover from prior sprint and P0 vs stretch labeling
- 6 standalone planning capabilities listed in SKILL.md flow diagram
Adoption & trust: 1.5k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a backlog and a date range but no clear sprint goals or realistic capacity after PTO, meetings, and last-sprint carryover.
Who is it for?
Indie teams running fixed-length sprints who want a repeatable planning ritual in the agent before touching Jira, Linear, or GitHub Projects.
Skip if: Quarterly OKR roadmapping, headcount org design, or fully automated sprint creation without human goal-setting—pair org-planning or connect tools explicitly.
When should I use this skill?
Kicking off a new sprint, sizing backlog against team availability (PTO, meetings), deciding P0 vs stretch, or handling carryover from the last sprint.
What do I get? / Deliverables
You leave with prioritized scope (P0 vs stretch), documented risks and dependencies, and a sprint plan ready to paste into your tracker or standup notes.
- Sprint plan document
- Sprint goals and success criteria
- Scoped and prioritized backlog for the iteration
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Sprint planning is the default PM ritual while actively building; it is the canonical shelf even when you repeat it in Operate for maintenance sprints. Backlog prioritization and capacity math are PM workflows, not security review or launch distribution.
Where it fits
Set a two-week sprint goal and cut scope after accounting for launch-week meetings.
Prioritize release checklist items as P0 and park nice-to-haves as stretch before ship week.
Plan a maintenance sprint focused on bugs and dependency upgrades with realistic solo capacity.
How it compares
Iteration-level sprint plan generator—not a full program-management suite or CI/CD pipeline skill.
Common Questions / FAQ
Who is sprint-planning for?
Solo builders and small teams shipping in sprints who need goals, capacity math, and a written plan each cycle.
When should I use sprint-planning?
At Build kickoff for a new sprint, when sizing backlog against availability including PTO, when splitting P0 vs stretch, or when carrying work forward—use /sprint-planning with optional sprint name or date range.
Is sprint-planning safe to install?
Core planning is standalone; optional supercharged connectors may reach project trackers and calendars—review the Security Audits panel on this Prism page and CONNECTORS.md before enabling integrations.
SKILL.md
READMESKILL.md - Sprint Planning
# /sprint-planning > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Plan a sprint by scoping work, estimating capacity, and setting clear goals. ## Usage ``` /sprint-planning $ARGUMENTS ``` ## How It Works ``` ┌─────────────────────────────────────────────────────────────────┐ │ SPRINT PLANNING │ ├─────────────────────────────────────────────────────────────────┤ │ STANDALONE (always works) │ │ ✓ Define sprint goals and success criteria │ │ ✓ Estimate team capacity (accounting for PTO, meetings) │ │ ✓ Scope and prioritize backlog items │ │ ✓ Identify dependencies and risks │ │ ✓ Generate sprint plan document │ ├─────────────────────────────────────────────────────────────────┤ │ SUPERCHARGED (when you connect your tools) │ │ + Project tracker: Pull backlog, create sprint, assign items │ │ + Calendar: Account for PTO and meetings in capacity │ │ + Chat: Share sprint plan with the team │ └─────────────────────────────────────────────────────────────────┘ ``` ## What I Need From You - **Team**: Who's on the team and their availability this sprint? - **Sprint length**: How many days/weeks? - **Backlog**: What's prioritized? (Pull from tracker, paste, or describe) - **Carryover**: Anything unfinished from last sprint? - **Dependencies**: Anything blocked on other teams? ## Output ```markdown ## Sprint Plan: [Sprint Name] **Dates:** [Start] — [End] | **Team:** [X] engineers **Sprint Goal:** [One clear sentence about what success looks like] ### Capacity | Person | Available Days | Allocation | Notes | |--------|---------------|------------|-------| | [Name] | [X] of [Y] | [X] points/hours | [PTO, on-call, etc.] | | **Total** | **[X]** | **[X] points** | | ### Sprint Backlog | Priority | Item | Estimate | Owner | Dependencies | |----------|------|----------|-------|--------------| | P0 | [Must ship] | [X] pts | [Person] | [None / Blocked by X] | | P1 | [Should ship] | [X] pts | [Person] | [None] | | P2 | [Stretch] | [X] pts | [Person] | [None] | ### Planned Capacity: [X] points | Sprint Load: [X] points ([X]% of capacity) ### Risks | Risk | Impact | Mitigation | |------|--------|------------| | [Risk] | [What happens] | [What to do] | ### Definition of Done - [ ] Code reviewed and merged - [ ] Tests passing - [ ] Documentation updated (if applicable) - [ ] Product sign-off ### Key Dates | Date | Event | |------|-------| | [Date] | Sprint start | | [Date] | Mid-sprint check-in | | [Date] | Sprint end / Demo | | [Date] | Retro | ``` ## Tips 1. **Leave buffer** — Plan to 70-80% capacity. You will get interrupts. 2. **One clear sprint goal** — If you can't state it in one sentence, the sprint is unfocused. 3. **Identify stretch items** — Know what to cut if things take longer than expected. 4. **Carry over honestly** — If something didn't ship, understand why before re-committing.