
Bmad Sprint Planning
- 311 installs
- 51.5k repo stars
- Updated August 5, 2026
- bmad-code-org/bmad-method
bmad-sprint-planning is a BMAD Method agent skill that plans upcoming sprints by breaking epics into sized stories, assigning priorities, and aligning capacity for developers before agents or engineers start implementati
About
bmad-sprint-planning is a bmad-code-org/bmad-method skill that runs agile sprint planning rituals within the BMAD spec-driven framework. It decomposes epics into sized user stories, assigns priorities, and aligns team capacity before agents or engineers begin implementation work. The skill sits between validated PRDs and execution workflows like bmad-quick-dev, ensuring backlog items are right-sized and sequenced for the upcoming iteration. BMAD Method provides scale-adaptive planning across 34+ workflows with specialized agents for PM, architect, and developer roles. Reach for bmad-sprint-planning at iteration boundaries when epics need story breakdown, priority ordering, or capacity checks against available agent and engineer bandwidth. Outputs become the sprint backlog that quick-dev sessions or manual implementation can consume, keeping BMAD planning artifacts synchronized with what actually ships each cycle.
- Backlog grooming prompts
- Story sizing and prioritization
- Capacity-aware commitment
- Acceptance criteria drafting
- Links to sprint status tracking
Bmad Sprint Planning by the numbers
- 311 all-time installs (skills.sh)
- Ranked #879 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/bmad-code-org/bmad-method --skill bmad-sprint-planningAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 311 |
|---|---|
| repo stars | ★ 51.5k |
| Last updated | August 5, 2026 |
| Repository | bmad-code-org/bmad-method ↗ |
How do you plan a BMAD sprint from epics?
Plan an upcoming sprint by breaking epics into sized stories, assigning priorities, and aligning capacity before agents or engineers start implementation.
Who is it for?
Development teams using BMAD Method who need structured epic-to-story breakdown and capacity planning at sprint boundaries.
Skip if: Single-story Quick Flow tasks that skip sprint ceremonies or teams without epics ready for decomposition.
When should I use this skill?
The user starts a new sprint, needs epic breakdown into stories, or must align capacity before implementation begins.
What you get
A prioritized sprint backlog with sized stories, assigned priorities, and capacity-aligned iteration plan.
- Prioritized sprint backlog
- Sized user stories
- Capacity alignment plan
By the numbers
- Part of BMAD Method framework with 34+ workflows
Files
Sprint Planning Workflow
Goal: Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file.
Your Role: You are a Developer generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml.
Conventions
- Bare paths (e.g.
checklist.md) resolve from the skill root. {skill-root}resolves to this skill's installed directory (wherecustomize.tomllives).{project-root}-prefixed paths resolve from the project working directory.{skill-name}resolves to the skill directory's basename.
On Activation
Step 1: Resolve the Workflow Block
Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow
If the script fails, resolve the workflow block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
1. {skill-root}/customize.toml — defaults 2. {project-root}/_bmad/custom/{skill-name}.toml — team overrides 3. {project-root}/_bmad/custom/{skill-name}.user.toml — personal overrides
Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by code or id replace matching entries and append new entries, and all other arrays append.
Step 2: Execute Prepend Steps
Execute each entry in {workflow.activation_steps_prepend} in order before proceeding.
Step 3: Load Persistent Facts
Treat every entry in {workflow.persistent_facts} as foundational context you carry for the rest of the workflow run. Entries prefixed file: are paths or globs under {project-root} — load the referenced contents as facts. All other entries are facts verbatim.
Step 4: Load Config
Load config from {project-root}/_bmad/bmm/config.yaml and resolve:
project_name,user_namecommunication_language,document_output_languageimplementation_artifactsplanning_artifactsdateas system-generated current datetimeproject_context=**/project-context.md(load if exists)- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config
{communication_language} - Generate all documents in
{document_output_language}
Step 5: Greet the User
Greet {user_name}, speaking in {communication_language}.
Step 6: Execute Append Steps
Execute each entry in {workflow.activation_steps_append} in order.
Activation is complete. If activation_steps_prepend or activation_steps_append were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
Paths
tracking_system=file-systemproject_key=NOKEYstory_location={implementation_artifacts}story_location_absolute={implementation_artifacts}epics_location={planning_artifacts}epics_pattern=*epic*.mdstatus_file={implementation_artifacts}/sprint-status.yaml
Input Files
| Input | Path | Load Strategy |
|---|---|---|
| Epics | {planning_artifacts}/*epic*.md (whole) or {planning_artifacts}/*epic*/*.md (sharded) | FULL_LOAD |
Execution
Document Discovery - Full Epic Loading
Strategy: Sprint planning needs ALL epics and stories to build complete status tracking.
Epic Discovery Process:
1. Search for whole document first - Look for epics.md, bmm-epics.md, or any *epic*.md file 2. Check for sharded version - If whole document not found, look for epics/index.md 3. If sharded version found:
- Read
index.mdto understand the document structure - Read ALL epic section files listed in the index (e.g.,
epic-1.md,epic-2.md, etc.) - Process all epics and their stories from the combined content
- This ensures complete sprint status coverage
4. Priority: If both whole and sharded versions exist, use the whole document
Fuzzy matching: Be flexible with document names - users may use variations like epics.md, bmm-epics.md, user-stories.md, etc.
<workflow>
<step n="1" goal="Parse epic files and extract all work items"> <action>Load {project_context} for project-wide patterns and conventions (if exists)</action> <action>Communicate in {communication_language} with {user_name}</action> <action>Look for all files matching {epics_pattern} in {epics_location}</action> <action>Could be a single epics.md file or multiple epic-1.md, epic-2.md files</action>
<action>For each epic file found, extract:</action>
- Epic numbers from headers like
## Epic 1:or## Epic 2: - Story IDs and titles from patterns like
### Story 1.1: User Authentication - Convert story format from
Epic.Story: Titleto kebab-case key:epic-story-title
Story ID Conversion Rules:
- Original:
### Story 1.1: User Authentication - Replace period with dash:
1-1 - Convert title to kebab-case:
user-authentication - Final key:
1-1-user-authentication
<action>Build complete inventory of all epics and stories from all epic files</action> </step>
<step n="2" goal="Build sprint status structure"> <action>For each epic found, create entries in this order:</action>
1. Epic entry - Key: epic-{num}, Default status: backlog 2. Story entries - Key: {epic}-{story}-{title}, Default status: backlog 3. Retrospective entry - Key: epic-{num}-retrospective, Default status: optional
Example structure:
development_status:
epic-1: backlog
1-1-user-authentication: backlog
1-2-account-management: backlog
epic-1-retrospective: optional</step>
<step n="3" goal="Apply intelligent status detection"> <action>For each story, detect current status by checking files:</action>
Story file detection:
- Check:
{story_location_absolute}/{story-key}.md(e.g.,stories/1-1-user-authentication.md) - If exists → upgrade status to at least
ready-for-dev
Preservation rule:
- If existing
{status_file}exists and has more advanced status, preserve it - Never downgrade status (e.g., don't change
donetoready-for-dev) - If existing
{status_file}has anaction_itemssection, carry it over unchanged
Status Flow Reference:
- Epic:
backlog→in-progress→done - Story:
backlog→ready-for-dev→in-progress→review→done - Retrospective:
optional↔done
</step>
<step n="4" goal="Generate sprint status file"> <action>Create or update {status_file} with:</action>
File Structure:
# generated: {date}
# last_updated: {date}
# project: {project_name}
# project_key: {project_key}
# tracking_system: {tracking_system}
# story_location: {story_location}
# STATUS DEFINITIONS:
# ==================
# Epic Status:
# - backlog: Epic not yet started
# - in-progress: Epic actively being worked on
# - done: All stories in epic completed
#
# Epic Status Transitions:
# - backlog → in-progress: Automatically when first story is created (via create-story)
# - in-progress → done: Manually when all stories reach 'done' status
#
# Story Status:
# - backlog: Story only exists in epic file
# - ready-for-dev: Story file created in stories folder
# - in-progress: Developer actively working on implementation
# - review: Ready for code review (via Dev's code-review workflow)
# - done: Story completed
#
# Retrospective Status:
# - optional: Can be completed but not required
# - done: Retrospective has been completed
#
# Action Item Status:
# - open: Committed during a retrospective, not yet addressed
# - in-progress: Actively being worked on
# - done: Completed
#
# WORKFLOW NOTES:
# ===============
# - Epic transitions to 'in-progress' automatically when first story is created
# - Stories can be worked in parallel if team capacity allows
# - Developer typically creates next story after previous one is 'done' to incorporate learnings
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
# - Retrospective appends its action items to action_items; sprint-status surfaces open ones
generated: { date }
last_updated: { date }
project: { project_name }
project_key: { project_key }
tracking_system: { tracking_system }
story_location: { story_location }
development_status:
# All epics, stories, and retrospectives in order<action>Write the complete sprint status YAML to {status_file}</action> <action>CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing</action> <action>Ensure all items are ordered: epic, its stories, its retrospective, next epic...</action> <action>If the existing file had an action_items section, write it back unchanged after development_status</action> </step>
<step n="5" goal="Validate and report"> <action>Perform validation checks:</action>
- [ ] Every epic in epic files appears in {status_file}
- [ ] Every story in epic files appears in {status_file}
- [ ] Every epic has a corresponding retrospective entry
- [ ] No development_status items in {status_file} that don't exist in epic files
- [ ] action_items section (if it existed) carried over unchanged
- [ ] All status values are legal (match state machine definitions)
- [ ] File is valid YAML syntax
<action>Count totals:</action>
- Total epics: {{epic_count}}
- Total stories: {{story_count}}
- Epics in-progress: {{in_progress_count}}
- Stories done: {{done_count}}
<action>Display completion summary to {user_name} in {communication_language}:</action>
Sprint Status Generated Successfully
- File Location: {status_file}
- Total Epics: {{epic_count}}
- Total Stories: {{story_count}}
- Epics In Progress: {{in_progress_count}}
- Stories Completed: {{done_count}}
Next Steps:
1. Review the generated {status_file} 2. Use this file to track development progress 3. Agents will update statuses as they work 4. Re-run this workflow to refresh auto-detected statuses
<action>Run: python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action> </step>
</workflow>
Additional Documentation
Status State Machine
Epic Status Flow:
backlog → in-progress → done- backlog: Epic not yet started
- in-progress: Epic actively being worked on (stories being created/implemented)
- done: All stories in epic completed
Story Status Flow:
backlog → ready-for-dev → in-progress → review → done- backlog: Story only exists in epic file
- ready-for-dev: Story file created (e.g.,
stories/1-3-plant-naming.md) - in-progress: Developer actively working
- review: Ready for code review (via Dev's code-review workflow)
- done: Completed
Retrospective Status:
optional ↔ done- optional: Ready to be conducted but not required
- done: Finished
Action Item Status:
open → in-progress → done- open: Committed during a retrospective, not yet addressed
- in-progress: Actively being worked on
- done: Completed
Guidelines
1. Epic Activation: Mark epic as in-progress when starting work on its first story 2. Sequential Default: Stories are typically worked in order, but parallel work is supported 3. Parallel Work Supported: Multiple stories can be in-progress if team capacity allows 4. Review Before Done: Stories should pass through review before done 5. Learning Transfer: Developer typically creates next story after previous one is done to incorporate learnings
Sprint Planning Validation Checklist
Core Validation
Complete Coverage Check
- [ ] Every epic found in epic\*.md files appears in sprint-status.yaml
- [ ] Every story found in epic\*.md files appears in sprint-status.yaml
- [ ] Every epic has a corresponding retrospective entry
- [ ] No development_status items in sprint-status.yaml that don't exist in epic files
- [ ] action_items section (if it existed) carried over unchanged
Parsing Verification
Compare epic files against generated sprint-status.yaml:
Epic Files Contains: Sprint Status Contains:
✓ Epic 1 ✓ epic-1: [status]
✓ Story 1.1: User Auth ✓ 1-1-user-auth: [status]
✓ Story 1.2: Account Mgmt ✓ 1-2-account-mgmt: [status]
✓ Story 1.3: Plant Naming ✓ 1-3-plant-naming: [status]
✓ epic-1-retrospective: [status]
✓ Epic 2 ✓ epic-2: [status]
✓ Story 2.1: Personality Model ✓ 2-1-personality-model: [status]
✓ Story 2.2: Chat Interface ✓ 2-2-chat-interface: [status]
✓ epic-2-retrospective: [status]Final Check
- [ ] Total count of epics matches
- [ ] Total count of stories matches
- [ ] All items are in the expected order (epic, stories, retrospective)
# DO NOT EDIT -- overwritten on every update.
#
# Workflow customization surface for bmad-sprint-planning. Mirrors the
# agent customization shape under the [workflow] namespace.
[workflow]
# --- Configurable below. Overrides merge per BMad structural rules: ---
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
# Steps to run before the standard activation (config load, greet).
# Overrides append. Use for pre-flight loads, compliance checks, etc.
activation_steps_prepend = []
# Steps to run after greet but before the workflow begins.
# Overrides append. Use for context-heavy setup that should happen
# once the user has been acknowledged.
activation_steps_append = []
# Persistent facts the workflow keeps in mind for the whole run
# (standards, compliance constraints, stylistic guardrails).
# Distinct from the runtime memory sidecar — these are static context
# loaded on activation. Overrides append.
#
# Each entry is either:
# - a literal sentence, e.g. "All stories must include testable acceptance criteria."
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
# (glob patterns are supported; the file's contents are loaded and treated as facts).
persistent_facts = [
"file:{project-root}/**/project-context.md",
]
# Scalar: executed when the workflow reaches its final step,
# after sprint-status.yaml is generated and validated. Override wins.
# Leave empty for no custom post-completion behavior.
on_complete = ""
# Sprint Status Template
# This is an EXAMPLE showing the expected format
# The actual file will be generated with all epics/stories from your epic files
# generated: {date}
# project: {project_name}
# project_key: {project_key}
# tracking_system: {tracking_system}
# story_location: {story_location}
# STATUS DEFINITIONS:
# ==================
# Epic Status:
# - backlog: Epic not yet started
# - in-progress: Epic actively being worked on
# - done: All stories in epic completed
#
# Story Status:
# - backlog: Story only exists in epic file
# - ready-for-dev: Story file created, ready for development
# - in-progress: Developer actively working on implementation
# - review: Implementation complete, ready for review
# - done: Story completed
#
# Retrospective Status:
# - optional: Can be completed but not required
# - done: Retrospective has been completed
#
# Action Item Status:
# - open: Committed during a retrospective, not yet addressed
# - in-progress: Actively being worked on
# - done: Completed
#
# WORKFLOW NOTES:
# ===============
# - Mark epic as 'in-progress' when starting work on its first story
# - Developer typically creates next story ONLY after previous one is 'done' to incorporate learnings
# - Dev moves story to 'review', then Dev runs code-review (fresh context, ideally different LLM)
# - Retrospective appends its action items to action_items; sprint-status surfaces open ones
# EXAMPLE STRUCTURE (your actual epics/stories will replace these):
generated: 05-06-2-2025 21:30
last_updated: 05-06-2-2025 21:30
project: My Awesome Project
project_key: NOKEY
tracking_system: file-system
story_location: "{story_location}"
development_status:
epic-1: backlog
1-1-user-authentication: done
1-2-account-management: ready-for-dev
1-3-plant-data-model: backlog
1-4-add-plant-manual: backlog
epic-1-retrospective: optional
epic-2: backlog
2-1-personality-system: backlog
2-2-chat-interface: backlog
2-3-llm-integration: backlog
epic-2-retrospective: optional
# Action items committed during retrospectives (section created by the retrospective workflow)
action_items:
- epic: 1
action: "Add error-handling review to the code review checklist"
owner: "Charlie"
status: open
Related skills
How it compares
Pick bmad-sprint-planning for iteration backlog grooming when bmad-quick-dev needs right-sized stories instead of raw epics.
FAQ
What does bmad-sprint-planning output?
bmad-sprint-planning outputs a prioritized sprint backlog with sized stories decomposed from epics and capacity alignment for the iteration. This backlog feeds bmad-quick-dev sessions or manual engineer implementation in the same BMAD project.
When should bmad-sprint-planning run in BMAD Method?
bmad-sprint-planning runs at sprint boundaries after PRD validation and before implementation. The skill ensures epics are broken into right-sized stories with priorities set before agents or engineers start coding.