| name | bmad-sprint-planning |
| description | Orchestration handoff bridge: emits and maintains sprint-status.yaml as the project's
sequencing system-of-record. Orders stories by epic then dependency, assigns parallel-set
(wave) membership, and drives the status lifecycle (backlog → ready-for-dev → in-progress
→ review → done) as a view — never as a metric.
Use when the user says "sequence the stories", "build the sprint status", "plan the waves",
"create sprint-status.yaml", "assign parallel sets", "order stories by dependency",
"what can run in parallel", "set up story sequencing", "initialize sprint tracking",
"ready the backlog", or "prepare for dev handoff". Also triggers on "sprint planning"
when the project already has epics defined.
SCOPE: SEQUENCING AND ORCHESTRATION ONLY. No velocity, no burndown, no committed points,
no coverage metrics. Capacity is expressed as wave width (concurrent story count), not
points. The final artifact is a ready-for-dev handoff manifest; implementation is
delegated to external dev tools.
|
| allowed-tools | Read, Write, Edit, Bash, Glob, Grep, TodoWrite |
BMAD Sprint Planning
Role: Sequencing & Handoff Bridge — Phase 4 orchestration
System-of-record: bmad-output/sprint-status.yaml
What This Skill Does
- Reads planning artifacts (PRD, architecture, epics, stories) from
bmad-output/.
- Derives a dependency graph across all stories.
- Assigns each story a
parallel_set (wave) — stories in the same wave have no mutual dependencies and can run concurrently.
- Emits
bmad-output/sprint-status.yaml using the canonical template.
- Marks the first wave of stories
ready-for-dev; all others remain backlog.
- Optionally re-sequences on demand as stories are completed or new ones are added.
This skill does not write application code, run tests, lint, build, or review diffs.
Three-Intent Operation
| Intent | Trigger phrase | Action |
|---|
| Create | "initialize sprint status", "first time" | Scaffold fresh sprint-status.yaml from template |
| Update | "re-sequence", "story X is done", "add story", "update wave" | Mutate existing sprint-status.yaml in-place |
| Validate | "check sequencing", "are dependencies correct", "show wave plan" | Read and report without writing |
Workflow — Create
-
Load planning artifacts
Glob: bmad-output/**/*.md, bmad-output/**/*.yaml
Priority order: epics.md → prd.md → architecture.md → individual story files.
-
Extract epics and stories
- Parse all story IDs: format
{epic}.{story}.{slug}.story.md (e.g., 2.1.stripe-integration.story.md)
- Derive epic ordering from the epic list in
epics.md or prd.md
-
Build dependency graph
- Read
dependencies[] from each story's frontmatter or Dev Notes section
- Topological sort: stories with no unmet dependencies → wave 1; stories unblocked after wave 1 → wave 2; etc.
-
Initialize sprint-status.yaml
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/init-sprint-status.sh
Then populate with sequenced data (see template).
-
Sequence stories
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/sequence-stories.sh
-
Set initial statuses
- Wave 1 stories:
status: ready-for-dev
- All other stories:
status: backlog
- Epics:
status: in-progress if any child story is ready-for-dev; else backlog
-
Emit handoff summary — list wave 1 stories by owned_scope for conflict-free parallel dispatch
Workflow — Update
When a story moves to done:
- Remove it from any
dependencies[] lists where it appears
- Identify newly unblocked stories (dependencies now fully satisfied)
- Promote them to
ready-for-dev
- Re-evaluate parent epic status
- Write updated
sprint-status.yaml
Parallel Set Assignment
Wave width (how many stories can run at once) is not a fixed number — it is the size of the dependency-free frontier at each topological level. There is no points budget or velocity ceiling.
Wave 1: all stories with no dependencies
Wave 2: all stories whose only dependencies are in wave 1
Wave N: all stories whose dependencies are fully in waves 1…(N-1)
Stories within a wave MUST have non-overlapping owned_scope to be safe for parallel dispatch. If two stories in the same wave share a file, split them into separate waves or document the conflict.
Status Lifecycle (view, not metric)
backlog → ready-for-dev → in-progress → review → done
- This is a view of sequencing state, not a tracking instrument.
- Transitions are triggered by external signals (dev tool reports, user command).
- This skill never computes velocity, burndown, or completion rates from these statuses.
Scale-Adaptive Track Guidance
| Track | Story count | Sprint-status behavior |
|---|
| Quick Flow | 1–15 | Single wave pass; minimal epic structure |
| BMAD Method | 10–50+ | Full wave assignment; epic grouping |
| Enterprise | 30+ | Multi-phase wave planning; dependency map documented in REFERENCE |
Track is confirmed with the user before generating the status file.
Subagent Strategy
Pattern: Parallel dependency analysis
Use when: 15+ stories across 3+ epics
| Agent | Task | Output |
|---|
| Agent 1 | Parse all story files, extract dependency declarations | bmad-output/context/dependency-raw.yaml |
| Agent 2 | Parse epic ordering from PRD/epics.md | bmad-output/context/epic-order.yaml |
| Agent 3 | Identify owned_scope conflicts within candidate waves | bmad-output/context/scope-conflicts.md |
Main context: merge outputs, run topological sort, write sprint-status.yaml.
Example subagent prompt
Task: Extract dependencies from all story files
Context: Read all *.story.md files under bmad-output/stories/
Objective: For each story, output its id and its dependencies[] list
Output: Write YAML list to bmad-output/context/dependency-raw.yaml
Format:
- id: "2.1.stripe-integration"
dependencies: ["1.3.user-auth"]
- id: "2.2.payment-webhook"
dependencies: ["2.1.stripe-integration"]
Scripts
init-sprint-status.sh
Scaffolds bmad-output/sprint-status.yaml from the template if it does not exist.
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/init-sprint-status.sh \
[project-name] [output-dir]
sequence-stories.sh
Orders stories: epics first (by epic number), then stories within each epic by dependency
(topological), then assigns parallel_set integers.
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/scripts/sequence-stories.sh \
[sprint-status-file]
Template
${CLAUDE_PLUGIN_ROOT}/skills/bmad-sprint-planning/templates/sprint-status.template.yaml
Fields: epics[], stories[] (with id, title, status, dependencies, parallel_set,
owned_scope). The template contains no velocity, burndown, or points fields.
Key Guidelines
- Load context first — always read existing
sprint-status.yaml before writing
- Use TodoWrite to track multi-step sequencing workflows
- Respect owned_scope — flag conflicts before assigning same-wave membership
- No metrics — if a field resembles velocity, points, or burndown, remove it
- Handoff clearly — conclude every Create/Update with the list of
ready-for-dev stories and their owned_scope
- Decision log — append sequencing decisions to
bmad-output/decision-log.md
Part of the BMAD Planning & Orchestrator plugin — a Claude Code harness for the BMAD Method by the BMAD Code Organization (https://github.com/bmad-code-org/BMAD-METHOD). Implements the spirit of bmad-sprint-planning. All methodology credit belongs to the BMAD Code Organization.
