Arckit Backlog

Generate Product Backlog

You are creating a prioritised product backlog for an ArcKit project, converting design artifacts into sprint-ready user stories.

User Input

$ARGUMENTS

Arguments

SPRINT_LENGTH (optional): Sprint duration (default: 2w)

• Valid: 1w, 2w, 3w, 4w

SPRINTS (optional): Number of sprints to plan (default: 8)

• Generates sprint plan for first N sprints

VELOCITY (optional): Team velocity in story points per sprint (default: 20)

• Adjusts sprint capacity planning

FORMAT (optional): Output formats (default: markdown)

• Valid: markdown, csv, json, all

PRIORITY (optional): Prioritization approach (default: multi)

• moscow - MoSCoW only
• risk - Risk-based only
• value - Value-based only
• dependency - Dependency-based only
• multi - Multi-factor (recommended)

What This Command Does

Scans all ArcKit artifacts and automatically:

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

Output: projects/{project-dir}/ARC-{PROJECT_ID}-BKLG-v1.0.md (+ optional CSV/JSON)

Time Savings: 75%+ reduction (4-6 weeks → 3-5 days)

Process

Step 1: Identify Project Context

Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

Use the ArcKit Project Context (above) to find the project matching the user's input (by name or number). If no match, create a new project:

1. Use Glob to list projects/*/ directories and find the highest NNN-* number (or start at 001 if none exist)
2. Calculate the next number (zero-padded to 3 digits, e.g., 002)
3. Slugify the project name (lowercase, replace non-alphanumeric with hyphens, trim)
4. Use the Write tool to create projects/{NNN}-{slug}/README.md with the project name, ID, and date — the Write tool will create all parent directories automatically
5. Also create projects/{NNN}-{slug}/external/README.md with a note to place external reference documents here
6. Set PROJECT_ID = the 3-digit number, PROJECT_PATH = the new directory path

Extract project metadata:

• Project name
• Current phase (from artifacts)
• Team size (if documented)

Step 2: Read existing artifacts from the project context

MANDATORY (warn if missing):

• REQ (Requirements) — primary source
  • Extract: All BR/FR/NFR/INT/DR requirement IDs, descriptions, priorities, acceptance criteria
  • If missing: warn user to run $arckit-requirements first — backlog is derived from requirements

RECOMMENDED (read if available, note if missing):

• STKE (Stakeholder Analysis)
  • Extract: User personas for "As a..." statements, stakeholder priorities
• RISK (Risk Register)
  • Extract: Risk priorities for risk-based prioritization, security threats
• SOBC (Business Case)
  • Extract: Value priorities, ROI targets for value-based prioritization
• PRIN (Architecture Principles, in 000-global)
  • Extract: Quality standards for Definition of Done
• HLDR (High-Level Design Review) or DLDR (Detailed Design Review)
  • Extract: Component names and responsibilities for story mapping
• HLD/DLD in projects/{project-dir}/vendors/*/hld-v*.md or dld-v*.md — Vendor designs
  • Extract: Component mapping, detailed component info

OPTIONAL (read if available, skip silently if missing):

• DPIA (Data Protection Impact Assessment)
  • Extract: Privacy-related tasks and constraints
• test-strategy.md — Test requirements (optional external document)
  • Extract: Test types and coverage needs

Step 2b: Read external documents and policies

• Read any external documents listed in the project context (external/ files) — extract existing user stories, velocity data, sprint history, team capacity, component architecture from vendor HLD/DLD documents
• Read any enterprise standards in projects/000-global/external/ — extract enterprise backlog standards, Definition of Ready/Done templates, cross-project estimation benchmarks
• If no external docs exist but they would improve backlog accuracy, ask: "Do you have any vendor design documents or existing backlog exports? I can read PDFs and images directly. Place them in projects/{project-dir}/external/ and re-run, or skip."
• Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

Step 2c: Interactive Configuration

Before generating the backlog, ask the user for user preferences. Skip any question where the user has already specified their choice via the arguments above (e.g., if they wrote PRIORITY=risk, do not ask about prioritization).

Gathering rules — the one-message interview in .arckit/references/interview-pattern.md:

• Prefill from the arguments and the project context; say what you inferred.
• Ask every remaining question in one call. There is no second round.
• An unanswered question takes its (Recommended) option, listed as an assumption in your closing summary. With no question tool available, take every default and never block.

Question 1 — header: Priority, multiSelect: false

"Which prioritization approach should be used for the backlog?"

• Multi-factor (Recommended): Combines MoSCoW, risk, value, and dependency scoring for balanced prioritization
• MoSCoW: Must/Should/Could/Won't categorization only
• Value vs Effort: Prioritize by business value relative to implementation effort
• Risk-based: Prioritize highest-risk items first to reduce uncertainty early

Question 2 — header: Format, multiSelect: false

"What output format do you need?"

• All formats (Recommended): Markdown report + CSV (Jira/Azure DevOps import) + JSON (API integration)
• Markdown only: Standard report document
• CSV only: For direct import into Jira, Azure DevOps, or GitHub Projects
• JSON only: For programmatic access and custom integrations

Apply the user's selections to the corresponding parameters throughout this command. For example, if they chose "MoSCoW", use only MoSCoW prioritization in Step 7 instead of the full multi-factor algorithm. If they chose "CSV only", generate only the CSV output in Step 13.

Step 3: Parse Requirements

For each requirement in the requirements document (ARC-*-REQ-*.md), extract:

Business Requirements (BR-xxx):

**BR-001**: User Management
- Description: [text]
- Priority: Must Have

→ Becomes an Epic

Functional Requirements (FR-xxx):

**FR-001**: User Registration
- Description: [text]
- Priority: Must Have
- Acceptance Criteria: [list]

→ Becomes a User Story

Non-Functional Requirements (NFR-xxx):

**NFR-005**: Response time < 2 seconds
- Implementation: Caching layer
- Priority: Should Have

→ Becomes a Technical Task

Integration Requirements (INT-xxx):

**INT-003**: Integrate with Stripe API
- Priority: Must Have

→ Becomes an Integration Story

Data Requirements (DR-xxx):

**DR-002**: Store user payment history
- Priority: Should Have

→ Becomes a Data Task

Create a mapping table:

Requirement ID → Story Type → Priority → Dependencies

Step 4: Generate User Stories from Functional Requirements

For each FR-xxx, create a user story in GDS format:

4.1: Identify the Actor (User Persona)

Look in the stakeholder analysis (ARC-*-STKE-*.md) for user types:

• Service users
• Administrators
• System operators
• API consumers
• Third-party integrators

Match the FR to the appropriate persona based on:

• Who performs this action?
• Who benefits from this capability?

Examples:

• FR about "user login" → "new user" or "registered user"
• FR about "admin dashboard" → "system administrator"
• FR about "API endpoint" → "API consumer"

If no persona matches, use generic:

• "user" for user-facing features
• "system" for backend/integration features
• "administrator" for admin features

4.2: Extract the Action (I want...)

From the FR description, identify the core capability:

• Action verbs: create, view, update, delete, process, integrate, export, import, search, filter, etc.
• Object: what is being acted upon

Examples:

• FR: "System shall allow users to register" → "create an account"
• FR: "System shall process payments" → "pay with my credit card"
• FR: "System shall export reports to CSV" → "export my data as CSV"

4.3: Infer the Goal (So that...)

Why does the user need this capability? Look for:

1. Explicit goal in FR description
2. Parent BR description
3. Business case benefits
4. User needs from stakeholder analysis

If goal not explicit, infer from context:

• Registration → "access the service"
• Payment → "complete my transaction"
• Export → "analyze data offline"
• Notification → "stay informed of updates"

4.4: Generate Acceptance Criteria

Convert FR's acceptance criteria to "It's done when..." format:

Original FR acceptance criteria:

- Email verification required
- Password must be 8+ characters
- GDPR consent must be captured

Convert to GDS format:

Acceptance Criteria:
- It's done when email verification is sent within 1 minute
- It's done when password meets security requirements (8+ chars, special char)
- It's done when GDPR consent is captured and stored
- It's done when confirmation email is received

Rules for acceptance criteria:

• Start with "It's done when..."
• Make measurable and testable
• Include success cases
• Include key error cases
• Reference NFRs (security, performance, compliance)
• Typically 3-6 criteria per story

4.5: Estimate Story Points

Use Fibonacci sequence: 1, 2, 3, 5, 8, 13

Estimation guidelines:

• 1 point: Trivial, < 2 hours

  • Config change
  • Simple UI text update
  • Add logging statement

• 2 points: Simple, half day

  • Small API endpoint (GET with no logic)
  • Basic UI form with validation
  • Database query with simple filter

• 3 points: Moderate, 1 day

  • API endpoint with business logic
  • UI component with state management
  • Database migration
  • Integration with simple external API

• 5 points: Complex, 2-3 days

  • Multi-step workflow
  • Complex business logic
  • UI feature with multiple components
  • Integration with authentication
  • Data migration script

• 8 points: Very complex, 1 week

  • Major feature spanning multiple components
  • Complex integration (payment gateway, SSO)
  • Significant refactoring
  • Multi-table data model

• 13 points: Epic-level, 2 weeks

  • Too large - break down into smaller stories
  • Example: "Build entire admin dashboard"

Factors that increase points:

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

Estimation algorithm:

Base points = 3 (typical story)

If FR involves:
  + Multiple components: +2
  + Security/auth: +2
  + External integration: +2
  + Data migration: +2
  + Complex validation: +1
  + Performance requirements: +2
  + GDPR/compliance: +1

Total = Base + modifiers
Round to nearest Fibonacci number
Cap at 13 (break down if larger)

4.6: Identify Component (from HLD)

Map story to HLD component:

• Read vendors/{vendor}/hld-v*.md for component list
• Match FR to component based on:
  • Component responsibilities
  • Component name (e.g., "User Service", "Payment Service")
  • FR description keywords

Example component mapping:

FR-001: User Registration → User Service
FR-005: Process Payment → Payment Service
FR-010: Send Email → Notification Service
FR-015: Generate Report → Reporting Service

If no HLD exists, infer component from FR:

• Authentication/user features → "User Service"
• Payment features → "Payment Service"
• Data/reporting → "Data Service"
• Integrations → "Integration Service"

4.7: Create Technical Tasks

Break down story into implementation tasks:

For a typical FR, create 2-4 tasks:

Story-001: Create user account (8 points)

Tasks:
- Task-001-A: Design user table schema (2 points)
  - PostgreSQL schema with email, password_hash, created_at
  - Add GDPR consent fields
  - Create indexes on email

- Task-001-B: Implement registration API endpoint (3 points)
  - POST /api/users/register
  - Email validation
  - Password hashing (bcrypt)
  - Return JWT token

- Task-001-C: Implement email verification service (3 points)
  - Generate verification token
  - Send email via SendGrid
  - Verify token endpoint
  - Mark user as verified

Task estimation:

• Tasks should sum to story points
• Typical split: 30% database, 40% API, 30% UI
• Add testing tasks if needed

4.8: Complete User Story Format

Final story structure:

### Story-{FR-ID}: {Short Title}

**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}
- It's done when {measurable outcome 3}
- It's done when {measurable outcome 4}

**Technical Tasks**:
- Task-{ID}-A: {task description} ({points} points)
- Task-{ID}-B: {task description} ({points} points)
- Task-{ID}-C: {task description} ({points} points)

**Requirements Traceability**: {FR-xxx, NFR-xxx, etc.}
**Component**: {from HLD}
**Story Points**: {1,2,3,5,8,13}
**Priority**: {Must Have | Should Have | Could Have | Won't Have}
**Sprint**: {calculated in Step 6}
**Dependencies**: {other story IDs that must be done first}

Example - Complete 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)

Step 5: Generate Epics from Business Requirements

For each BR-xxx, create an epic:

5.1: Epic Structure

## Epic {BR-ID}: {BR Title}

**Business Requirement**: {BR-ID}
**Priority**: {Must Have | Should Have | Could Have}
**Business Value**: {High | Medium | Low} - {description from business case}
**Risk**: {Critical | High | Medium | Low} - {from risk register}
**Dependencies**: {other epic IDs that must be done first}
**Total Story Points**: {sum of all stories in epic}
**Estimated Duration**: {points / velocity} sprints

**Description**:
{BR description from ARC-*-REQ-*.md}

**Success Criteria**:
{BR acceptance criteria}

**Stories in this Epic**:
{List all FR stories that map to this BR}

---

5.2: Group Stories into Epics

Use this mapping logic:

1. Explicit BR → FR mapping:

   • If FR references a BR (e.g., "Relates to BR-001"), group there

2. Semantic grouping:

   • User-related FRs → "User Management" epic
   • Payment-related FRs → "Payment Processing" epic
   • Integration FRs → "External Integrations" epic

3. HLD component grouping:

   • All stories for "User Service" → User Management epic
   • All stories for "Payment Service" → Payment Processing epic

Example Epic:

## Epic 1: User Management (BR-001)

**Business Requirement**: BR-001
**Priority**: Must Have
**Business Value**: High - Foundation for all user-facing features
**Risk**: Medium - GDPR compliance required
**Dependencies**: None (foundation epic)
**Total Story Points**: 34
**Estimated Duration**: 2 sprints (at 20 points/sprint)

**Description**:
System must provide comprehensive user management including registration,
authentication, profile management, and password reset. Must comply with
UK GDPR and provide audit trail for all user data access.

**Success Criteria**:
- Users can create accounts with email verification
- Users can login and logout securely
- User sessions expire after 30 minutes of inactivity
- Password reset functionality available
- GDPR consent captured and audit trail maintained

**Stories in this Epic**:
1. Story-001: Create user account (8 points) - Sprint 1
2. Story-002: User login (5 points) - Sprint 1
3. Story-003: User logout (2 points) - Sprint 1
4. Story-004: Password reset (5 points) - Sprint 2
5. Story-005: Update user profile (3 points) - Sprint 2
6. Story-006: Delete user account (5 points) - Sprint 2
7. Story-007: View audit log (3 points) - Sprint 2
8. Story-008: Export user data (GDPR) (3 points) - Sprint 2

**Total**: 34 story points across 8 stories

---

Step 6: Create Technical Tasks from NFRs

For each NFR-xxx, create a technical task:

6.1: Technical Task Structure

### Task-{NFR-ID}: {Short Title}

**Type**: Technical Task (NFR)
**Requirement**: {NFR-ID}
**Priority**: {Must Have | Should Have | Could Have}
**Story Points**: {1,2,3,5,8,13}
**Sprint**: {calculated in Step 7}

**Description**:
{What needs to be implemented to satisfy this NFR}

**Acceptance Criteria**:
- It's done when {measurable outcome 1}
- It's done when {measurable outcome 2}
- It's done when {measurable outcome 3}

**Dependencies**: {stories/tasks that must exist first}
**Component**: {affected component from HLD}

6.2: NFR → Task Examples

Performance NFR:

### Task-NFR-005: Implement Redis caching layer

**Type**: Technical Task (NFR)
**Requirement**: NFR-005 (Response time < 2 seconds P95)
**Priority**: Should Have
**Story Points**: 5
**Sprint**: 2

**Description**:
Implement Redis caching to meet response time requirements. Cache frequently
accessed data including user sessions, product catalog, and search results.

**Acceptance Criteria**:
- It's done when Redis is deployed and configured in all environments
- It's done when cache hit rate > 80% for user sessions
- It's done when P95 response time < 2 seconds for cached endpoints
- It's done when cache invalidation strategy is implemented
- It's done when cache monitoring dashboard shows hit/miss rates

**Dependencies**: Task-001-A (database schema must exist), Story-002 (login creates sessions)
**Component**: Infrastructure, User Service, Product Service

Security NFR:

### Task-NFR-012: Implement rate limiting

**Type**: Technical Task (NFR)
**Requirement**: NFR-012 (DDoS protection)
**Priority**: Must Have
**Story Points**: 3
**Sprint**: 1

**Description**:
Implement API rate limiting to prevent abuse and DDoS attacks.
Limit: 100 requests per minute per IP, 1000 per hour.

**Acceptance Criteria**:
- It's done when rate limiter middleware is implemented
- It's done when 429 status code returned when limit exceeded
- It's done when rate limits vary by endpoint (stricter for auth)
- It's done when rate limit headers included in responses
- It's done when rate limit bypass available for known good IPs

**Dependencies**: Task-001-B (API must exist)
**Component**: API Gateway

Compliance NFR:

### Task-NFR-008: Implement GDPR audit logging

**Type**: Technical Task (NFR)
**Requirement**: NFR-008 (GDPR compliance)
**Priority**: Must Have
**Story Points**: 5
**Sprint**: 2

**Description**:
Implement comprehensive audit logging for all user data access to comply
with UK GDPR Article 30 (records of processing activities).

**Acceptance Criteria**:
- It's done when all user data access is logged (who, what, when, why)
- It's done when logs stored immutably (append-only)
- It's done when logs retained for 7 years
- It's done when logs available for GDPR data subject access requests
- It's done when logs include IP address, user agent, action type

**Dependencies**: Task-001-A (user table must exist), Story-001 (users must exist)
**Component**: Audit Service, User Service

Step 7: Prioritization

Apply multi-factor prioritization algorithm:

7.1: Calculate Priority Score

For each story/task, calculate:

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

MoSCoW Weight:

• Must Have = 4
• Should Have = 3
• Could Have = 2
• Won't Have = 1

Risk Weight (from ARC-*-RISK-*.md):

• Critical risk = 4
• High risk = 3
• Medium risk = 2
• Low risk = 1

Value Weight (from ARC-*-SOBC-*.md):

• High ROI/impact = 4
• Medium ROI/impact = 3
• Low ROI/impact = 2
• No ROI data = 1

Dependency Weight:

• Blocks many items (>5) = 4
• Blocks some items (3-5) = 3
• Blocks few items (1-2) = 2
• Blocks nothing = 1

Example calculation:

Story-001: Create user account
  MoSCoW: Must Have = 4
  Risk: Medium (GDPR) = 2
  Value: High (foundation) = 4
  Dependency: Blocks many (all user features) = 4

Priority Score = (4 * 0.4) + (2 * 0.2) + (4 * 0.2) + (4 * 0.2)
               = 1.6 + 0.4 + 0.8 + 0.8
               = 3.6

Story-025: Export user preferences
  MoSCoW: Could Have = 2
  Risk: Low = 1
  Value: Low = 2
  Dependency: Blocks nothing = 1

Priority Score = (2 * 0.4) + (1 * 0.2) + (2 * 0.2) + (1 * 0.2)
               = 0.8 + 0.2 + 0.4 + 0.2
               = 1.6

7.2: Sort Backlog

Sort all stories/tasks by Priority Score (descending):

Story-001: Create user account (3.6)
Story-002: User login (3.4)
Task-NFR-012: Rate limiting (3.2)
Story-015: Connect to Stripe (3.0)
Story-016: Process payment (3.0)
...
Story-025: Export preferences (1.6)

7.3: Dependency Enforcement

After sorting by priority, adjust for mandatory dependencies:

Foundation Stories (always Sprint 1):

• Authentication (user registration, login)
• Database setup
• CI/CD pipeline
• Testing framework

Dependency Rules:

2. Technical foundation before features:

   • Auth system before user-facing features
   • Database before data operations
   • API gateway before API endpoints

3. Integration points before dependent features:

   • Stripe API integration before payment UI
   • Email service before notifications
   • Search service before search features

4. Parent stories before child stories:

   • "Create user account" before "Update user profile"
   • "Process payment" before "View payment history"

Dependency adjustment algorithm:

For each story S in sorted backlog:
  If S has dependencies D1, D2, ..., Dn:
    For each dependency Di:
      If Di is not scheduled yet or scheduled after S:
        Move Di before S
        Recursively check Di's dependencies

Example - Before dependency adjustment:

Sprint 1:
  Story-016: Process payment (3.0) - depends on Story-015

Sprint 2:
  Story-015: Connect to Stripe (3.0)

After dependency adjustment:

Sprint 1:
  Story-015: Connect to Stripe (3.0) - no dependencies

Sprint 2:
  Story-016: Process payment (3.0) - depends on Story-015 ✓

Step 8: Sprint Planning

Organise stories into sprints with capacity planning:

8.1: Sprint Parameters

Default values (overridden by arguments):

• Velocity: 20 story points per sprint
• Sprint length: 2 weeks
• Number of sprints: 8

Capacity allocation per sprint:

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

8.2: Sprint 1 - Foundation Sprint

Sprint 1 is special - always includes:

Must-have foundation items:

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

Example Sprint 1:

## Sprint 1: Foundation (Weeks 1-2)

**Velocity**: 20 story points
**Theme**: Technical foundation and core infrastructure

### Must Have Stories (12 points):
- Story-001: Create user account (8 points) [Epic: User Management]
- Story-002: User login (5 points) [Epic: User Management]
  → Reduced to fit capacity, move Story-003 to Sprint 2

### Technical Tasks (4 points):
- Task-DB-001: Setup PostgreSQL database (2 points) [Epic: Infrastructure]
- Task-CI-001: Setup CI/CD pipeline with GitHub Actions (2 points) [Epic: DevOps]

### Testing Tasks (3 points):
- Task-TEST-001: Setup Jest testing framework (1 point) [Epic: Testing]
- Test-001: Unit tests for user registration (included in Story-001)
- Test-002: Integration test for login flow (included in Story-002)

### Security Tasks (1 point):
- Task-NFR-012: Implement rate limiting (1 point) [Epic: Security]

**Total Allocated**: 20 points

### Sprint Goals:
✅ Users can create accounts and login
✅ Database deployed to dev/staging/prod
✅ CI/CD pipeline operational (deploy on merge)
✅ Unit testing framework ready
✅ Basic security controls in place

### Dependencies Satisfied:
✅ None (foundation sprint)

### Dependencies Created for Sprint 2:
→ User authentication (Story-001, Story-002)
→ Database schema (Task-DB-001)
→ CI/CD (Task-CI-001)
→ Testing (Task-TEST-001)

### Risks:
⚠️ GDPR compliance review needed for Story-001
⚠️ Email service selection (SendGrid vs AWS SES) for Story-001
⚠️ Team may be unfamiliar with CI/CD tools

### Definition of Done:
- [ ] All code reviewed and approved
- [ ] Unit tests written (80% coverage minimum)
- [ ] Integration tests written for critical paths
- [ ] Security scan passed (no critical/high issues)
- [ ] Deployed to dev environment
- [ ] Demo-able to stakeholders at sprint review
- [ ] Documentation updated (API docs, README)

8.3: Subsequent Sprints (2-N)

For each sprint after Sprint 1:

Step 1: Calculate available capacity

Total capacity = Velocity (default 20 points)
Feature capacity = 60% = 12 points
Technical capacity = 20% = 4 points
Testing capacity = 15% = 3 points
Buffer = 5% = 1 point

Step 2: Select stories by priority

Starting from top of prioritised backlog:

For each unscheduled story S (sorted by priority):
  If S's dependencies are all scheduled in earlier sprints:
    If S's points <= remaining_capacity_for_type:
      Add S to current sprint
      Reduce remaining capacity
    Else:
      Try next story (S won't fit)
  Else:
    Skip S (dependencies not met)

Continue until sprint is full or no more stories fit

Step 3: Balance work types

Ensure sprint has mix of:

• Feature stories (user-facing value)
• Technical tasks (infrastructure, NFRs)
• Testing tasks (quality)

If sprint has too many of one type, swap with next sprint.

Step 4: Validate dependencies

For each story in sprint:

• Check all dependencies are in earlier sprints
• If dependency missing, move it to current sprint (adjust capacity)

Example Sprint 2:

## 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]
  - Dependencies: ✅ Story-001 (users must be authenticated)
- Story-003: Password reset (5 points) [Epic: User Management]
  - Dependencies: ✅ Story-001, Story-002
  → Only 13 points for features (adjusted)

### Technical Tasks (4 points):
- Task-NFR-005: Implement Redis caching layer (3 points) [Epic: Performance]
  - Dependencies: ✅ Task-DB-001 (database must exist)
- Task-NFR-008: GDPR audit logging (2 points) [Epic: Compliance]
  - Dependencies: ✅ Story-001 (users must exist)
  → Only 5 points for technical (adjusted)

### 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 (13+5+2)

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

### Dependencies Satisfied:
✅ Sprint 1: User authentication, database, CI/CD

### Dependencies Created for Sprint 3:
→ Stripe integration (Story-015) - needed for payment workflows
→ Caching infrastructure (Task-NFR-005) - improves all features

### Risks:
⚠️ Stripe sandbox environment access needed
⚠️ PCI-DSS compliance requirements for Story-015
⚠️ Redis cluster setup for production

### Testing Focus:
- Integration tests for Stripe API (webhooks, payments)
- GDPR audit log verification
- Cache invalidation testing

8.4: Generate All Sprint Plans

Continue for all N sprints (default 8):

## Sprint 3: Feature Build (Weeks 5-6)
[... sprint details ...]

## Sprint 4: Integration (Weeks 7-8)
[... sprint details ...]

## Sprint 5: Advanced Features (Weeks 9-10)
[... sprint details ...]

## Sprint 6: Security Hardening (Weeks 11-12)
[... sprint details ...]

## Sprint 7: Performance Optimization (Weeks 13-14)
[... sprint details ...]

## Sprint 8: UAT Preparation (Weeks 15-16)
[... sprint details ...]

## Future Sprints (Beyond Week 16)

**Remaining Backlog**: {X} story points
**Estimated Duration**: {X / velocity} sprints

**High Priority Items for Sprint 9+**:
- Story-045: Advanced reporting (8 points)
- Story-052: Mobile app integration (13 points)
- Task-NFR-025: Multi-region deployment (8 points)
[... list remaining high-priority items ...]

Step 9: Generate Traceability Matrix

Create comprehensive traceability table:

## Appendix A: Requirements Traceability Matrix

| Requirement | Type | User Stories | Sprint | Status | Notes |
|-------------|------|-------------|--------|--------|-------|
| BR-001 | Business | Story-001, Story-002, Story-003, Story-004, Story-005, Story-006, Story-007, Story-008 | 1-2 | Planned | User Management epic |
| FR-001 | Functional | Story-001 | 1 | Planned | User registration |
| FR-002 | Functional | Story-002 | 1 | Planned | User login |
| FR-003 | Functional | Story-003 | 2 | Planned | Password reset |
| FR-005 | Functional | Story-016 | 2 | Planned | Process payment |
| NFR-005 | Non-Functional | Task-NFR-005 | 2 | Planned | Caching for performance |
| NFR-008 | Non-Functional | Task-NFR-008 | 2 | Planned | GDPR audit logging |
| NFR-012 | Non-Functional | Task-NFR-012 | 1 | Planned | Rate limiting |
| INT-003 | Integration | Story-015 | 2 | Planned | Stripe integration |
| DR-002 | Data | Task-DR-002 | 3 | Planned | Payment history schema |
[... all requirements mapped ...]

**Coverage Summary**:
- Total Requirements: {N}
- Mapped to Stories: {N} (100%)
- Scheduled in Sprints 1-8: {N} ({X}%)
- Remaining for Future Sprints: {N} ({X}%)

Step 9b: Load Mermaid Syntax Reference

Read .arckit/skills/mermaid-syntax/references/flowchart.md for official Mermaid syntax — node shapes, edge labels, subgraphs, and styling options.

Step 10: Generate Dependency Graph

Create visual dependency representation:

## Appendix B: Dependency Graph

### Sprint 1 → Sprint 2 Dependencies

```mermaid
flowchart TD
    subgraph S1[Sprint 1 - Foundation]
        S001[Story-001: User Registration]
        S002[Story-002: User Login]
        TDB[Task-DB-001: Database Setup]
        TCI[Task-CI-001: CI/CD Pipeline]
    end

    subgraph S2[Sprint 2]
        S015[Story-015: Needs authenticated users]
        S003[Story-003: Needs user accounts]
        TNFR5[Task-NFR-005: Needs database for caching]
        TNFR8[Task-NFR-008: Needs database for audit log]
    end

    subgraph Future[All Future Work]
        FW[Deploy mechanism required]
    end

    S001 -->|blocks| S015
    S001 -->|blocks| S003
    S002 -->|blocks| S015
    TDB -->|blocks| TNFR5
    TDB -->|blocks| TNFR8
    TCI -->|blocks| FW

    style S1 fill:#E3F2FD
    style S2 fill:#FFF3E0
    style Future fill:#E8F5E9
```text

### Sprint 2 → Sprint 3 Dependencies

```mermaid
flowchart TD
    subgraph S2[Sprint 2 - Core Features]
        S015[Story-015: Stripe Integration]
        NFR5[Task-NFR-005: Redis Caching]
        NFR8[Task-NFR-008: GDPR Audit Log]
    end

    subgraph S3[Sprint 3]
        S016[Story-016: Payment processing needs Stripe]
    end

    subgraph S4[Sprint 4]
        S025[Story-025: Payment history needs payments]
        S030[Story-030: GDPR data export]
    end

    subgraph S3Plus[Sprint 3+]
        ALL[All features benefit from caching]
    end

    S015 -->|blocks| S016
    S015 -->|blocks| S025
    NFR5 -->|improves| ALL
    NFR8 -->|enables| S030

    style S2 fill:#E3F2FD
    style S3 fill:#FFF3E0
    style S4 fill:#E8F5E9
    style S3Plus fill:#F3E5F5
```text

[... continue for all sprints ...]

Step 11: Generate Epic Overview

Create epic summary table:

## Appendix C: Epic Overview

| Epic ID | Epic Name | Priority | Stories | Points | Sprints | Status | Dependencies |
|---------|-----------|----------|---------|--------|---------|--------|--------------|
| EPIC-001 | User Management | Must Have | 8 | 34 | 1-2 | Planned | None |
| EPIC-002 | Payment Processing | Must Have | 12 | 56 | 2-4 | Planned | EPIC-001 |
| EPIC-003 | Stripe Integration | Must Have | 6 | 28 | 2-3 | Planned | EPIC-001 |
| EPIC-004 | Reporting | Should Have | 10 | 42 | 5-6 | Planned | EPIC-002 |
| EPIC-005 | Admin Dashboard | Should Have | 8 | 35 | 4-5 | Planned | EPIC-001 |
| EPIC-006 | Email Notifications | Should Have | 5 | 18 | 3-4 | Planned | EPIC-001 |
| EPIC-007 | Mobile API | Could Have | 7 | 29 | 7-8 | Planned | EPIC-002 |
| EPIC-008 | Advanced Search | Could Have | 6 | 24 | 6-7 | Planned | EPIC-004 |
[... all epics ...]

**Total**: {N} epics, {N} stories, {N} story points

Step 12: Generate Definition of Done

Extract from ARC-000-PRIN-*.md or use defaults:

## Appendix D: Definition of Done

Every story must meet these criteria before marking "Done":

### Code Quality
- [ ] Code reviewed by 2+ team members
- [ ] No merge conflicts
- [ ] Follows coding standards (linting passed)
- [ ] No code smells or technical debt introduced

### Testing
- [ ] Unit tests written (minimum 80% coverage)
- [ ] Integration tests written for API endpoints
- [ ] Manual testing completed
- [ ] Acceptance criteria verified and signed off

### Security
- [ ] Security scan passed (no critical/high vulnerabilities)
- [ ] OWASP Top 10 checks completed
- [ ] Secrets not hardcoded (use environment variables)
- [ ] Authentication and authorisation tested

### Performance
- [ ] Performance tested (meets NFR thresholds)
- [ ] No N+1 query issues
- [ ] Caching implemented where appropriate
- [ ] Response times < 2 seconds (P95)

### Compliance
- [ ] GDPR requirements met (if handling user data)
- [ ] Accessibility tested (WCAG 2.2 AA)
- [ ] Audit logging in place (if required)

### Documentation
- [ ] API documentation updated (OpenAPI/Swagger)
- [ ] Code comments for complex logic
- [ ] README updated if needed
- [ ] Runbook updated (if operational changes)

### Deployment
- [ ] Deployed to dev environment
- [ ] Deployed to staging environment
- [ ] Database migrations tested (if applicable)
- [ ] Configuration updated in all environments

### Stakeholder
- [ ] Demoed to Product Owner at sprint review
- [ ] Acceptance criteria validated by PO
- [ ] User feedback incorporated (if available)

---

**Note**: This DoD applies to all stories. Additional criteria may be added per story based on specific requirements.

Step 13: Generate Output Files

13.1: Primary Output - ARC--BKLG-.md

Read the template (user override takes precedence):

• First, check .arckit/templates-custom/backlog-template.md
• Then, .arckit/templates-custom/backlog-template.md
• Fallback, .arckit/templates/backlog-template.md
• Then read .arckit/templates/_partials/RENDERING.md and resolve the <!-- DOC-CONTROL-HEADER --> marker in the template before writing. Do not hand-write the Document Control table: the partial RENDERING.md selects is the only source of the 14 standard fields and of the classification ladder.

The template owns the document structure. Populate it from Steps 3-12 — do not invent a parallel one.

Write it with the Write tool to projects/{project-dir}/ARC-{PROJECT_ID}-BKLG-v1.0.md. A backlog is long, so writing it inline risks the 32K output-token limit.

13.2: CSV Export (if requested)

Create backlog.csv for Jira/Azure DevOps import:

Type,Key,Epic,Summary,Description,Acceptance Criteria,Priority,Story Points,Sprint,Status,Component,Requirements
Epic,EPIC-001,,"User Management","Foundation epic for user management including registration, authentication, profile management",,Must Have,34,1-2,To Do,User Service,BR-001
Story,STORY-001,EPIC-001,"Create user account","As a new user I want to create an account so that I can access the service","It's done when I can enter email and password; It's done when email verification is sent; It's done when account is created after verification; It's done when GDPR consent is rec

…(truncated)