Sprint Planning
Use this skill to plan a work cycle (sprint) with clear objective, selected items, and execution order.
Initial context received via slash: $ARGUMENTS
If
is filled, use as reference (e.g., epic, backlog, period).
If empty, ask which backlog or initiative will be planned.
Language
Write the artifact in the user's language. Apply correct grammar and any required diacritics or script-specific characters. If the user's language is unclear, ask before generating output. Templates are in English — translate headers and content to match.
Project root
This skill writes artifacts at paths relative to the project root (the repo where the work happens), not the agent's current working directory.
- If invoked from inside the project, use the relative paths shown in this skill.
- If invoked from another directory (e.g., a sibling repo, or when the project lives elsewhere), prepend to every artifact path.
- When the project root is ambiguous, confirm with the user via the harness question tool before writing.
Prompting
Follow the project-wide convention in
/
("Skill Prompting Conventions"). Use the harness's structured-question tool —
(Claude Code),
(Codex), or
(OpenCode) — for the decision points below. Use free-form text only where a path/name/value cannot be enumerated.
| Decision point | Why structured | Suggested options |
|---|
| Backlog items to include (multi-select) | Affects sprint scope | select from backlog list |
| Sprint duration | Affects capacity math | 1 week · 2 weeks · custom |
Free-form prompts (no structured tool):
- Sprint goal text
- Capacity overrides
No-pause mode: if the user has explicitly disabled mid-skill clarification, convert every structured prompt into an entry under Open questions (or equivalent) and proceed without blocking.
Objective
- Declare the sprint objective
- Select backlog items based on value, risk, and dependency
- Record capacity and constraints
- Define execution order and highlight blockers
- Validate that each item has Definition of Ready
Process
1. Declare objective
- What should the sprint deliver as an observable result?
- One phrase that guides trade-off decisions during the sprint
2. Review backlog
Consult:
- Epic with pending stories
- Retro with pending improvement actions
- Backlog items that have been validated via
3. Select items
For each selected item, register:
- Name and objective
- Estimated size
- Value (why now?)
- Dependencies and blockers
4. Validate DoR
Each item must have:
- Clear problem and objective
- Scope and out of scope recorded
- Files/areas mapped
- Verifiable acceptance criteria
- Test-first path for product behavior, especially validation, API contracts, permissions, offline/sync behavior, and critical flows
If an item doesn't have DoR, it doesn't enter the sprint — needs decomposition via
or validation via
.
5. Order execution
- What must be done first (unblocks the rest)?
- What can run in parallel?
- What is the critical path?
6. Distribute across team
When 2+ developers are available:
- Assign items to developers or tracks (e.g., Backend, Frontend)
- Identify items that can be worked on simultaneously
- Define interface contracts or mocks to avoid blocking between tracks
- Use Mermaid diagrams to visualize parallel assignments
7. Register commitments
- Available capacity (days, constraints, number of developers)
- Sprint commitment (selected items, assigned to whom)
- What is left out (postponed items)
Where to save
planning/<initiative>/sprints/sprint-YYYY-MM-DD.md
planning/sprints/sprint-YYYY-MM-DD.md
Chaining
- To detail the first item: suggest for the first story in the backlog
- For items that need decomposition: suggest
- For items that need validation: suggest
- For process or skill friction discovered while planning: suggest
Reference template
Use
from this skill as base.
Rules
- Don't select more items than capacity allows. Over-commitment generates frustration and inconsistency.
- Each item must have DoR. Without DoR, it doesn't enter the sprint.
- The sprint objective must be observable, not vague.
- Dependencies must be explicit — don't assume "it will fit".
- Sprint planning feeds execution. If planning doesn't generate clarity, execution will suffer.
Relationship with the flow
mermaid
flowchart LR
A["/agile-retro"] --> B["/agile-sprint"]
B --> C["/agile-story"]
C --> D[execution]
D --> E["/agile-status"]
E --> F["/agile-review"]
F --> G["/agile-retro"]
This skill starts the sprint cycle. For decomposing work, use
. For execution plans, use
. For tracking during the sprint, use
.