# Arckit Backlog

> Generate prioritised product backlog from ArcKit artifacts - convert requirements to user stories, organise into sprints

- Skill: `tractorjuice/arckit-backlog` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tractorjuice/arckit-backlog`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tractorjuice/arckit-backlog/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: tractorjuice (https://skillmd.com/u/tractorjuice)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tractorjuice/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

```text
$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**

   ```text
   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)**:

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

→ Becomes an **Epic**

**Functional Requirements (FR-xxx)**:

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

→ Becomes a **User Story**

**Non-Functional Requirements (NFR-xxx)**:

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

→ Becomes a **Technical Task**

**Integration Requirements (INT-xxx)**:

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

→ Becomes an **Integration Story**

**Data Requirements (DR-xxx)**:

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

→ Becomes a **Data Task**

Create a mapping table:

```text
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**:

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

**Convert to GDS format**:

```text
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**:

```text
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:

```text
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:

```text
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**:

```markdown
### 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**:

```markdown
### 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

```markdown
## 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**:

```markdown
## 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

```markdown
### 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**:

```markdown
### 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**:

```markdown
### 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**:

```markdown
### 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:

```text
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**:

```text
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):

```text
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**:

```text
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**:

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

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

**After dependency adjustment**:

```text
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**:

```markdown
## 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**

```text
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:

```text
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**:

```markdown
## 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):

```markdown
## 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:

```markdown
## 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:

```markdown
## 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:

```markdown
## 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:

```markdown
## 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.

| Template section | Filled from |
|---|---|
| **Executive Summary** | totals, priority breakdown and epic breakdown from Steps 4-7 |
| **How to Use This Backlog** | ships complete; keep it, and set the refinement schedule to the sprint length chosen in Step 2c |
| **Epics** | Step 5, one block per BR-xxx |
| **Prioritized Backlog** | Steps 4 and 7, one `Story-NNN` block per story in priority order |
| **Sprint Plan** | Step 8, one block per sprint with goals, dependencies, risks and the Definition of Done |
| **Appendices A-F** | A from Step 9, B from Step 10, C from Step 11, D from the Step 7 points distribution, E from the Step 7 risk-based ordering, F from Step 12 |
| **Future Sprints** | the remainder of the ordered backlog beyond the planned sprints |
| **Backlog Maintenance** | ships complete — velocity tracking, grooming cadence, and when to re-generate |
| **Integration with Other ArcKit Commands** | ships complete |
| **External References** | the document register, citations and unreferenced documents, per the citation instructions read in Step 2b |

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:

```csv
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)