Iteration: Stories & Tasks

Iteration happens per epic. You take a feature-level epic and break it into sprint-ready work items: user stories with acceptance criteria and implementation tasks.

Step 5: Break Down User Stories

Slice an epic into vertical user stories that each deliver end-to-end value.

The AI applies vertical slicing: each story delivers a thin slice of functionality from UI to database, rather than a horizontal layer. Stories are validated against the INVEST framework:

• Independent: can be developed without waiting for other stories
• Negotiable: details are open for discussion
• Valuable: delivers something useful to the user
• Estimable: small enough to estimate confidently
• Small: fits in a single sprint
• Testable: has clear pass/fail criteria

Before candidates are even triaged, the AI reads the project's recorded decisions (ADRs, decision log) and its context map, scoped to what the epic touches: a candidate contradicting a live decision is reshaped or dropped, whatever a decision shaped is cited in the generated story ((per ADR-013), (per context-map: macrostate)), and a candidate that genuinely reopens a decision is flagged Revisits <id> in the proposal rather than silently contradicting it. Fresh project with no decisions yet? Generation behaves exactly as before, see Adoption files.

Before a story is created, it's triaged against stories already linked to the epic, proposed as EXTEND #ID or CREATE, same pattern as epic breakdown (see Strategic Planning). INVEST validation still applies to every CREATE candidate; an EXTEND re-validates INVEST for the merged scope.

Step 6: Refine a User Story

Transform a rough story into a development-ready specification.

Refinement opens with a phase 0 alignment gate: the AI runs a /pair-capability-grill shared-understanding sync (goal, acceptance criteria, edge cases, dependencies, design, and risks) one question at a time, and no readiness section is authored until you and the AI explicitly agree. It's a blocking gate: an unaligned story never proceeds to Ready.

Refinement reads the same adoption context as story breakdown, acceptance criteria and the technical approach follow (and cite) decisions already recorded, and an approach that reopens one is flagged Revisits <id> for you to accept or reject.

Refinement then adds these to a story:

Acceptance Criteria (Given-When-Then)

Given the user is on the login page
When they enter valid credentials and click "Sign in"
Then they are redirected to the dashboard
And their session is active for 24 hours

Every AC is testable: either it passes or it doesn't.

Technical Analysis

• Implementation approach (files to create/modify)
• Integration points (APIs, services, databases)
• Technical risks and mitigations
• Dependencies on other stories or external systems

Story Sizing

Story points using the team's estimation methodology. The AI proposes a size based on complexity and the team validates.

Classification Matrix

Refinement also shifts classification left: /pair-capability-classify scores the story against the quality model (risk and cost dimensions, coupling fed by the scoped subdomain/context mapping) and writes the matrix into the story's ## Classification section, so the risk tier is known before a line of code is written, not first surfaced at review.

What you see on the card. A ## Classification section: the resulting tier up front, then one line per dimension with its value, where it came from and a short note, collapsed under a <details> so the card stays readable. When the project projects tags, the card also carries the risk:* tag. The dimensions and tiers themselves are defined in Tag-Driven Quality Gates and the Quality Model.

What you are asked to confirm. Classification is a proposal: the refinement reports the matrix and you accept it or correct a dimension you know better (a story that actually touches a critical service, say). The tier is derived from the story's declared scope (a story that names no deployable falls back to the project's defaults) so a vague scope is the usual reason to correct it here rather than at review.

Review later re-classifies from the real diff; that side is in Execution.

Step 7: Create Tasks

Break a refined story into concrete implementation tasks.

Tasks are documented inline in the story body, not as separate issues. Each task includes:

• Implementation approach and files to touch
• Acceptance criteria mapped to the parent story's AC
• Dependency graph showing task ordering
• TDD approach (for development tasks)

Task Types

AC Coverage Table

Every acceptance criterion maps to at least one task:

| AC   | Tasks   |
| AC-1 | T-1     |
| AC-2 | T-2     |
| AC-3 | T-2, T-3|

No orphan ACs, no orphan tasks.

What You Have After Iteration

PM Tool:
├── Epic 1: Authentication & Registration
│   ├── Story: User can register with email (Ready, 3 pts)
│   │   ├── T-1: Registration API endpoint
│   │   ├── T-2: Registration form UI
│   │   ├── T-3: Email verification flow
│   │   └── T-4: E2E tests
│   ├── Story: User can log in (Ready, 2 pts)
│   │   ├── T-1: Login API endpoint
│   │   ├── T-2: Login form UI
│   │   └── T-3: Session management
│   └── Story: User can reset password (Ready, 3 pts)
│       └── ...

Every story is development-ready: clear AC, technical approach, sized, with tasks.

Next: Execution, implement stories and review code.