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:

code

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

Example:

code

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