Stage 10 - Sprints

Plan and execute agile development sprints, breaking down the product requirements into manageable backlogs with clear acceptance criteria, developer test plans, and QA verification points to deliver incremental, demo-able product milestones.

When to Use This Skill

User asks to start stage 10 (sprints)
User wants to plan sprints or create backlogs
User asks about feature development or sprint execution

Your Roles in This Skill

See dev-swarm/docs/general-dev-stage-rule.md for role selection guidance.

Role Communication

See dev-swarm/docs/general-dev-stage-rule.md for the required role announcement format.

Pre-Stage Check

Before starting, verify previous stages:

Check if 00-init-ideas/ through 09-devops/ folders have content (not just .gitkeep)
If any previous stage is empty and has no SKIP.md:
- Ask user: "Stage {XX} is not complete. Would you like to skip it or start from that stage first?"

AI-Driven Development Sprint and Backlog Guidelines

See dev-swarm/docs/sprint-backlog-guidelines.md & dev-swarm/docs/what-is-a-feature.md

Instructions

Checklist formatting rule: Any checklist, acceptance criteria, or test plan must use Markdown task lists (e.g., - [ ] item) so QA can mark verification status.

Step 1: Context Review

Read all files to understand the project:

ideas.md
00-init-ideas/*.md through 09-devops/*.md - All markdown files

Step 2: Create Stage Proposal

General Rules: See dev-swarm/docs/general-dev-stage-rule.md → "Create Stage Proposal Rules" section.

If this stage is skipped (has SKIP.md), execute the next non-skipped stage's agent skill. Otherwise, create the file 10-sprints/README.md with the following content:

2.1 Stage Goal

Brief the goal in 2-3 paragraphs:

What this stage aims to achieve (sprint planning, backlog creation, development execution)
Why agile sprint development is critical for iterative delivery
How this transforms technical specifications into working software
What deliverables will be produced

2.2 Sprint Overview

Provide a high-level sprint breakdown:

Total number of sprints planned for MVP delivery
Sprint naming convention: SPRINT-XX-descriptive-name/ (e.g., SPRINT-01-user-auth/)
Brief description of what each sprint will deliver

2.3 Backlog Naming Convention

Explain the backlog file naming convention:

Format: [BACKLOG_TYPE]-XX-[feature-name]-<sub-feature>.md
BACKLOG_TYPE: FEATURE, CHANGE, BUG, or IMPROVE
XX: Two-digit sequence number (01, 02, etc.)
feature-name: The feature this backlog relates to
sub-feature: Optional sub-feature specifier
Example: FEATURE-01-user-auth-login.md, BUG-02-user-auth-session.md

2.4 Request User Approval

Ask user: "Please check the Stage Proposal in 10-sprints/README.md. Update it directly or tell me how to update it."

Step 3: Create Development Plan

Once user approves README.md, create 10-sprints/development-plan.md:

Sprint Breakdown: For each sprint, document:

Sprint number and name
Sprint goal (one sentence)
Features/backlogs included
Dependencies on previous sprints
Demo criteria
QA test plan (checkbox list)

Backlog Details: For each backlog item, document:

Backlog ID and unique keywords
User story format
Acceptance criteria (checkbox list)
Developer test plan (checkbox list)
Related files from previous stages
Estimated complexity (S/M/L)

Step 4: Create Sprint Folders and Backlogs

Once user approves the development plan:

4.1 Create Sprint Folders

For each sprint, create:

10-sprints/SPRINT-XX-descriptive-name/
├─ README.md                                          # Sprint overview
└─ [BACKLOG_TYPE]-XX-[feature-name]-<sub-feature>.md  # Individual backlogs

Example:

10-sprints/SPRINT-01-user-auth/
├─ README.md
├─ FEATURE-01-user-auth-login.md
├─ FEATURE-02-user-auth-register.md
└─ FEATURE-03-user-auth-session.md

4.2 Sprint README.md Structure

Each sprint's README.md should contain:

Sprint status (pending/in_progress/completed/blocked)
Sprint goal
Dependencies
Backlogs with status and complexity
Sprint test plan (checkbox list)
Demo script
Success criteria (checkbox list)

4.3 Backlog File Structure

Each backlog file should contain:

Keywords (unique across project)
User story
Related documentation references
Acceptance criteria (checkbox list)
Technical implementation notes
Developer test plan (checkbox list)
Dependencies
Complexity estimate
Status checklist (checkbox list)

Step 5: Finalize Sprint Documentation

Once user approves all sprint and backlog files:

5.1 Documentation Finalization

Sync 10-sprints/README.md to remove any deleted files
Ensure all backlog keywords are unique across the project
Verify all backlogs trace back to PRD requirements
Confirm all test plans are complete

5.2 Announce Documentation Complete

Inform user:

"Sprint planning documentation is complete and ready for development"
Summary of sprints and backlogs created
Total estimated complexity
Recommended sprint order

Stage Completion Rules

See dev-swarm/docs/general-dev-stage-rule.md for stage completion, commit, and skip rules.

Key Principles

Each backlog must be independently testable
Each sprint must be demo-able
Document all dependencies clearly
Trace all backlogs to PRD requirements
Support smooth transition to deployment

dev-swarm-stage-sprints