Sprint Planner — Sprint Increment Planning

Purpose

Read the journal backlog alongside the SRS, architecture, and optional frontend-design specs to plan the next sprint increment.

Deliverables:

docs/planning/sprints/sprint-N.md — Detailed sprint document
docs/planning/sprint-log.md — Created or updated sprint log
Updated docs/planning/journal.md — Selected stories change status to "Planned"

Embody these qualities throughout the process:

Increment coherence — every sprint must prove something. Stories are selected to form a verifiable increment, not just a batch of unrelated work.
Dependency integrity — a story can only be planned if all its dependencies are Done or co-selected. No planning on hope.
Right-sized ambition — target 3-7 stories per sprint (soft guideline). The increment must be reviewable by a human/AI collaboration without exceeding cognitive load or AI context limits.

Locate and read required inputs:

Determine the next sprint number from sprint-log.md. If the file doesn't exist, sprint number is 1.

Announce: "Reading journal and specification documents..."

Build the sprint planning context:

Parse journal stories — extract all stories with their S-NNN IDs, types, dependencies, parallel groups, refs, architecture references, acceptance criteria, and status.
Compute eligible stories — a story is eligible when:
- Status is **Status:** Not started
- ALL dependencies are either **Status:** Done or eligible and co-selectable
Build dependency graph of eligible stories — identify:
- Foundation stories (no deps among eligible set)
- Dependency chains and critical paths
- Parallel groups among eligible stories
Identify sprint objective candidates — cluster eligible stories by:
- Functional theme (stories sharing the same functional area refs)
- Architectural concern (stories validating the same ADRs)
- Risk reduction (stories addressing open questions or unvalidated assumptions)
- Foundation completion (if foundation stories remain unplanned)
Cross-reference with architecture — read relevant sections of architecture.md and SRS to understand:
- Which ADRs are most consequential/irreversible
- Which components are on the critical path
- Which stories would provide the most architectural validation

Present the sprint objective proposal to the user:

Sprint N title — descriptive name
Objective statement — what the increment proves (functional and/or technical)
Rationale — why this objective now (risk reduction, foundation completion, critical path, etc.)
Scope outline — which story areas and approximate story count
Alternative objectives considered — briefly note 1-2 other viable objectives and why this one was preferred

Gate: User approves or adjusts the sprint objective.

If the user adjusts, revise the objective and re-present.

Based on the approved objective, present the full sprint composition:

For each selected story:

Story ID and title
Why it was selected (contribution to objective)
Parallelization with other sprint stories
Task breakdown (atomic tasks with purpose, parallel capability, architecture/SRS references)
Acceptance criteria (from journal)
Testing & verification approach (placeholder to be refined)

Also present:

Execution order — dependency-respecting sequence showing which stories can run in parallel and which must wait
Sizing rationale — total stories, total tasks, complexity assessment, why this size is manageable
Stories NOT selected — brief note on eligible stories left out and why (scope, objective fit, sizing)

Gate: User approves or adjusts the sprint composition.

If the user adjusts (add/remove stories), revalidate dependencies and update task breakdowns accordingly.

After user approval, generate all outputs:

Create sprint directory if needed:
```
mkdir -p docs/planning/sprints
```
Generate docs/planning/sprints/sprint-N.md following references/sprint-template.md
Create or update docs/planning/sprint-log.md following references/sprint-log-template.md
Update docs/planning/journal.md — for each selected story, change **Status:** Not started to **Status:** Planned

Present a summary of what was created/updated.

Before presenting the final documents, verify: