Sprint Planning

​

What This Command Does

1. Converts requirements to user stories
   • Business Requirements (BR-xxx) → Epics
   • Functional Requirements (FR-xxx) → User Stories (GDS format)
   • Non-Functional Requirements (NFR-xxx) → Technical Tasks
   • Integration Requirements (INT-xxx) → Integration Stories
   • Data Requirements (DR-xxx) → Data Tasks
2. Generates GDS-compliant user stories

As a [persona]
I want [capability]
So that [goal]

Acceptance Criteria:
- It's done when [measurable outcome 1]
- It's done when [measurable outcome 2]

3. Prioritizes using multi-factor scoring
   • MoSCoW priorities (Must/Should/Could/Won’t)
   • Risk-based (from risk register)
   • Value-based (from business case)
   • Dependency-based (technical foundation first)
4. Organizes into sprint plan
   • Respects dependencies (auth before features)
   • Balances work types (60% features, 20% technical, 15% testing, 5% buffer)
   • Creates realistic sprint backlogs
5. Maintains traceability
   • Requirements → Stories → Sprints → Code
   • Links to HLD components
   • Maps to epics and business goals

​

When to Run This Command

• MANDATORY: Requirements document (ARC-*-REQ-*.md)
• RECOMMENDED:
  • Stakeholder Analysis (ARC-*-STKE-*.md) for user personas
  • Risk Register (ARC-*-RISK-*.md) for risk-based prioritization
  • Business Case (ARC-*-SOBC-*.md) for value-based prioritization
  • HLD/DLD for component mapping

​

Basic Usage

# Generate backlog with defaults (20 points/sprint, 8 sprints)
/arckit.backlog

# Custom velocity and sprint count
/arckit.backlog VELOCITY=25 SPRINTS=12

# Export all formats (Markdown + CSV + JSON)
/arckit.backlog FORMAT=all

# Risk-based prioritization only
/arckit.backlog PRIORITY=risk

​

Arguments

​

GDS User Story Format

​

Example Story

### Story-001: Create user account

**As a** new user
**I want** to create an account with email and password
**So that** I can access the service and save my preferences

**Acceptance Criteria**:
- It's done when I can enter email and password on registration form
- It's done when email verification is sent within 1 minute
- It's done when account is created after I verify my email
- It's done when GDPR consent is captured and stored
- It's done when invalid email shows error message
- It's done when weak password shows strength requirements

**Technical Tasks**:
- Task-001-A: Design user table schema with GDPR fields (2 points)
- Task-001-B: Implement POST /api/users/register endpoint (3 points)
- Task-001-C: Implement email verification service using SendGrid (3 points)

**Requirements Traceability**: FR-001, NFR-008 (GDPR), NFR-012 (Email)
**Component**: User Service (from HLD)
**Story Points**: 8
**Priority**: Must Have
**Sprint**: 1 (calculated)
**Dependencies**: None (foundation story)

​

Story Point Estimation

​

Factors That Increase Points

• Multiple components involved (API + UI + database): +2
• Security requirements (authentication, encryption): +2
• Third-party integration (external APIs): +2
• Data migration or transformation: +2
• Complex business logic: +1
• Performance optimization needed: +2
• Regulatory compliance (GDPR, PCI-DSS): +1

​

Prioritization Algorithms

​

Multi-Factor (Default)

Priority Score = (
  MoSCoW_Weight * 40% +
  Risk_Weight * 20% +
  Value_Weight * 20% +
  Dependency_Weight * 20%
)

• Must Have = 4, Should Have = 3, Could Have = 2, Won’t Have = 1
• Critical Risk = 4, High = 3, Medium = 2, Low = 1
• High Value = 4, Medium = 3, Low = 2, Unknown = 1
• Blocks Many (>5) = 4, Blocks Some (3-5) = 3, Blocks Few (1-2) = 2, Blocks Nothing = 1

​

MoSCoW Only

/arckit.backlog PRIORITY=moscow

​

Risk-Based

/arckit.backlog PRIORITY=risk

​

Value-Based

/arckit.backlog PRIORITY=value

​

Dependency-Based

/arckit.backlog PRIORITY=dependency

​

Sprint Planning

​

Sprint 1 - Foundation Sprint

1. User authentication (registration + login)
2. Database setup
3. CI/CD pipeline
4. Testing framework
5. Basic security (rate limiting, CORS)

• 60% Feature stories (12 points)
• 20% Technical tasks (4 points)
• 15% Testing tasks (3 points)
• 5% Bug buffer (1 point)

​

Subsequent Sprints

1. Select stories by priority (from multi-factor score)
2. Enforce dependencies (can’t do payment UI before Stripe integration)
3. Balance work types (features + technical + testing)
4. Respect velocity (don’t overcommit)

​

Example Sprint Plan

## Sprint 2: Core Features (Weeks 3-4)

**Velocity**: 20 story points
**Theme**: Payment integration and core workflows

### Feature Stories (12 points):
- Story-015: Connect to Stripe API (8 points) [Epic: Payment Processing]
- Story-003: Password reset (5 points) [Epic: User Management]

### Technical Tasks (4 points):
- Task-NFR-005: Implement Redis caching layer (3 points) [Epic: Performance]
- Task-NFR-008: GDPR audit logging (2 points) [Epic: Compliance]

### Testing Tasks (3 points):
- Task-TEST-002: Setup integration tests (Supertest) (2 points)
- Test-015: Stripe integration tests (included in Story-015)

**Total Allocated**: 20 points

### Sprint Goals:
- Stripe payment integration operational
- Password reset workflow complete
- Caching layer improves performance
- GDPR audit trail in place

​

Output Files

​

1. Markdown Report (Always)

• Executive summary with metrics
• All epics with story counts
• Prioritized backlog (all stories)
• Sprint plan (8 sprints by default)
• Traceability matrix (requirements → stories → sprints)
• Dependency graph (Mermaid diagrams)
• Definition of Done

​

2. CSV Export (If Requested)

• Type, Key, Epic, Summary, Description
• Acceptance Criteria, Priority, Story Points
• Sprint, Status, Component, Requirements

​

3. JSON Export (If Requested)

{
  "project": "payment-gateway",
  "summary": { "total_stories": 87, "total_points": 342 },
  "epics": [ ... ],
  "stories": [ ... ],
  "sprints": [ ... ],
  "traceability": [ ... ]
}

​

Exporting to Trello

# Step 1: Generate backlog with JSON export
/arckit.backlog FORMAT=json

# Step 2: Export to Trello
/arckit.trello

• Sprint-based lists (Product Backlog + Sprint 1-8 + In Progress + Done)
• Cards with story points, acceptance criteria, and priority labels
• Color-coded by MoSCoW priority and requirement type

export TRELLO_API_KEY="your-api-key"
export TRELLO_TOKEN="your-token"

​

Traceability Matrix

• Total Requirements: 85
• Mapped to Stories: 85 (100%)
• Scheduled in Sprints 1-8: 68 (80%)
• Remaining for Future Sprints: 17 (20%)

​

Best Practices

​

1. Run After Requirements Finalized

• ❌ Too early: During requirements gathering (requirements still changing)
• ✅ Right time: After requirements approved and HLD reviewed
• ❌ Too late: After Sprint 1 starts (team needs backlog to plan)

​

2. Review and Refine

1. Review with Product Owner (validate priorities)
2. Review with Tech Lead (validate estimates and dependencies)
3. Review with Team (validate feasibility)
4. Adjust stories, estimates, and sprint assignments

​

3. Calibrate Velocity

• After Sprint 1: Calculate actual velocity (sum of “Done” story points)
• Adjust Sprint 2+ capacity accordingly
• Track velocity trend (improving, stable, declining)

​

4. Groom Regularly

• Weekly: Refine next 2 sprints (details, estimates)
• Bi-weekly: Groom backlog beyond 2 sprints (priorities)
• Monthly: Review epic priorities (business changes)
• Per sprint: Update based on completed work

​

5. Track Dependencies

• Technical dependencies: X must exist before Y (auth before features)
• Business dependencies: A delivers value before B
• Resource dependencies: Same person needed for both

​

Real-World Examples

​

Example 1: NHS Appointment Booking

/arckit.backlog VELOCITY=18 SPRINTS=10 FORMAT=all PRIORITY=multi

• 12 epics, 87 stories, 342 story points
• Sprint 1: NHS Spine integration, user authentication
• Sprint 2-4: Core booking workflows
• Sprint 5-7: GP practice integration
• Sprint 8-10: Reporting and analytics
• Estimated duration: 20 weeks (10 sprints × 2 weeks)

​

Example 2: Payment Gateway

/arckit.backlog VELOCITY=25 SPRINTS=6 PRIORITY=dependency

• 6 epics, 52 stories, 198 story points
• Sprint 1: Stripe API integration, webhook handling
• Sprint 2: Payment processing (card, bank transfer)
• Sprint 3: Refunds and disputes
• Sprint 4: Recurring subscriptions
• Sprint 5: Payment analytics dashboard
• Sprint 6: PCI-DSS compliance hardening

​

Time Savings

• Convert requirements: 2-3 weeks
• Prioritize and sequence: 1 week
• Sprint planning: 1 week
• Total: 4-6 weeks (80-120 hours)

• Run command: 2-5 minutes
• Review and refine: 1-2 days
• Team refinement: 2-3 days
• Total: 3-5 days (24-40 hours)

​

Troubleshooting

​

No Requirements Found

​

Stories Not Mapped to Components

​

Generic User Personas

​

Velocity Too High/Low

# If team completed 15 points in Sprint 1
/arckit.backlog VELOCITY=15

​

Further Reading

• Traceability Guide - Track requirements to stories to sprints
• Customizing Templates - Customize backlog template
• Upgrading Guide - Preserve backlog format during upgrades