Sprint Planning

ArcKit’s /arckit.backlog command transforms requirements into sprint-ready user stories following the GDS (Government Digital Service) format, with automatic prioritization and traceability.

What This Command Does

The /arckit.backlog command automatically:

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

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)
Organizes into sprint plan
- Respects dependencies (auth before features)
- Balances work types (60% features, 20% technical, 15% testing, 5% buffer)
- Creates realistic sprint backlogs
Maintains traceability
- Requirements → Stories → Sprints → Code
- Links to HLD components
- Maps to epics and business goals

When to Run This Command

Timing: After HLD approval, before Sprint 1 (Alpha → Beta transition) Prerequisites:

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

Argument	Default	Options	Description
`SPRINT_LENGTH`	`2w`	`1w`, `2w`, `3w`, `4w`	Sprint duration
`SPRINTS`	`8`	Any number	Number of sprints to plan
`VELOCITY`	`20`	Any number	Team velocity (story points/sprint)
`FORMAT`	`markdown`	`markdown`, `csv`, `json`, `all`	Output formats
`PRIORITY`	`multi`	`moscow`, `risk`, `value`, `dependency`, `multi`	Prioritization approach

GDS User Story Format

ArcKit generates user stories following the GDS Service Manual 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

ArcKit uses Fibonacci sequence: 1, 2, 3, 5, 8, 13

Points	Effort	Examples
1	Trivial, < 2 hours	Config change, simple UI text update
2	Simple, half day	Small API endpoint (GET with no logic), basic form
3	Moderate, 1 day	API endpoint with business logic, UI component with state
5	Complex, 2-3 days	Multi-step workflow, complex business logic, auth integration
8	Very complex, 1 week	Major feature spanning multiple components, payment gateway
13	Epic-level, 2 weeks	Too large - break down into smaller stories

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

AI-generated story points are estimates only. Teams should:

Review and re-estimate based on their velocity
Use team poker for consensus
Track actual vs estimated over sprints
Adjust future estimates based on learnings

Prioritization Algorithms

Multi-Factor (Default)

Combines all factors for balanced prioritization:

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

Weights:

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

Prioritize by Must/Should/Could/Won’t:

/arckit.backlog PRIORITY=moscow

Use when: Business priorities are clear and trump all other factors.

Risk-Based

Prioritize highest-risk items first:

/arckit.backlog PRIORITY=risk

Use when: Reducing uncertainty is the top goal.

Value-Based

Prioritize by business value relative to effort:

/arckit.backlog PRIORITY=value

Use when: Maximizing ROI is the primary driver.

Dependency-Based

Prioritize items that unblock others:

/arckit.backlog PRIORITY=dependency

Use when: Technical foundation must be built in strict order.

Sprint Planning

Sprint 1 - Foundation Sprint

Sprint 1 is special - always includes:

User authentication (registration + login)
Database setup
CI/CD pipeline
Testing framework
Basic security (rate limiting, CORS)

Capacity Allocation:

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

Subsequent Sprints

For Sprints 2-N:

Select stories by priority (from multi-factor score)
Enforce dependencies (can’t do payment UI before Stripe integration)
Balance work types (features + technical + testing)
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

The command generates up to 3 files in projects/{project-dir}/:

1. Markdown Report (Always)

File: ARC-{PROJECT_ID}-BKLG-v1.0.md Contents:

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)

File: ARC-{PROJECT_ID}-BKLG-v1.0.csv Use: Import into Jira, Azure DevOps, or GitHub Projects Columns:

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

3. JSON Export (If Requested)

File: ARC-{PROJECT_ID}-BKLG-v1.0.json Use: Programmatic access, custom integrations Structure:

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

Exporting to Trello

After generating the backlog, use /arckit.trello to push it to Trello:

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

# Step 2: Export to Trello
/arckit.trello

This creates a Trello board with:

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

Prerequisites: Set environment variables:

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

See Trello API documentation for API credentials.

Traceability Matrix

The backlog includes a comprehensive traceability matrix:

Requirement	Type	User Stories	Sprint	Status	Notes
BR-001	Business	Story-001, Story-002, Story-003, Story-004	1-2	Planned	User Management epic
FR-001	Functional	Story-001	1	Planned	User registration
FR-002	Functional	Story-002	1	Planned	User login
NFR-005	Non-Functional	Task-NFR-005	2	Planned	Caching for performance
INT-003	Integration	Story-015	2	Planned	Stripe integration

Coverage Metrics:

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

Don’t generate backlog too early:

❌ 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

AI-generated backlog is a starting point:

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

3. Calibrate Velocity

Initial velocity (default 20) is assumed:

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

Backlog grooming schedule:

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

Dependencies are identified automatically but may need adjustment:

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

Project: NHS appointment booking system Command:

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

Result:

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

Project: Stripe payment gateway integration Command:

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

Result:

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

Manual backlog creation:

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

With /arckit.backlog:

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

Time savings: 75-85%

Troubleshooting

No Requirements Found

Error: No ARC-*-REQ-*.md file found Fix: Run /arckit.requirements first to generate requirements.

Stories Not Mapped to Components

Warning: Stories will not be mapped to components Fix: Run /arckit.diagram or provide HLD file with component names.

Generic User Personas

Warning: Using generic personas Fix: Run /arckit.stakeholders to identify user types.

Velocity Too High/Low

Sprints are under/over-allocated. Fix: Adjust velocity after Sprint 1 based on actual completed points:

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

Get Started

Core Concepts

Governance Workflow

Vendor Procurement

Design & Review

UK Government Compliance

Guides

Documentation Index

​What This Command Does

​When to Run This Command

​Basic Usage

​Arguments

​GDS User Story Format

​Example Story

​Story Point Estimation

​Factors That Increase Points

​Prioritization Algorithms

​Multi-Factor (Default)

​MoSCoW Only

​Risk-Based

​Value-Based

​Dependency-Based

​Sprint Planning

​Sprint 1 - Foundation Sprint

​Subsequent Sprints

​Example Sprint Plan

​Output Files

​1. Markdown Report (Always)

​2. CSV Export (If Requested)

​3. JSON Export (If Requested)

​Exporting to Trello

​Traceability Matrix

​Best Practices

​1. Run After Requirements Finalized

​2. Review and Refine

​3. Calibrate Velocity

​4. Groom Regularly

​5. Track Dependencies

​Real-World Examples

​Example 1: NHS Appointment Booking

​Example 2: Payment Gateway

​Time Savings

​Troubleshooting

​No Requirements Found

​Stories Not Mapped to Components

​Generic User Personas

​Velocity Too High/Low

​Further Reading

What This Command Does

When to Run This Command

Basic Usage

Arguments

GDS User Story Format

Example Story

Story Point Estimation

Factors That Increase Points

Prioritization Algorithms

Multi-Factor (Default)

MoSCoW Only

Risk-Based

Value-Based

Dependency-Based

Sprint Planning

Sprint 1 - Foundation Sprint

Subsequent Sprints

Example Sprint Plan

Output Files

1. Markdown Report (Always)

2. CSV Export (If Requested)

3. JSON Export (If Requested)

Exporting to Trello

Traceability Matrix

Best Practices

1. Run After Requirements Finalized

2. Review and Refine

3. Calibrate Velocity

4. Groom Regularly

5. Track Dependencies

Real-World Examples

Example 1: NHS Appointment Booking

Example 2: Payment Gateway

Time Savings

Troubleshooting

No Requirements Found

Stories Not Mapped to Components

Generic User Personas

Velocity Too High/Low

Further Reading