Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
bmad-code-org avatar

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-planning

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs311
repo stars51.5k
Last updatedAugust 5, 2026
Repositorybmad-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

SKILL.mdMarkdownGitHub ↗

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 (where customize.toml lives).
  • {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_name
  • communication_language, document_output_language
  • implementation_artifacts
  • planning_artifacts
  • date as system-generated current datetime
  • project_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-system
  • project_key = NOKEY
  • story_location = {implementation_artifacts}
  • story_location_absolute = {implementation_artifacts}
  • epics_location = {planning_artifacts}
  • epics_pattern = *epic*.md
  • status_file = {implementation_artifacts}/sprint-status.yaml

Input Files

InputPathLoad 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.md to 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: Title to 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 done to ready-for-dev)
  • If existing {status_file} has an action_items section, carry it over unchanged

Status Flow Reference:

  • Epic: backlogin-progressdone
  • Story: backlogready-for-devin-progressreviewdone
  • Retrospective: optionaldone

</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

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.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.