Slicing Stories

Slicing Stories

Transforms epics into a story map of vertical slices — each independently deployable and directly testable against user value.

The Core Principle: Vertical vs. Horizontal

A vertical slice cuts through all layers of the system (UI → API → DB → AI component) to deliver one unit of user value. It can be shipped and measured independently.

A horizontal slice (anti-pattern) implements one layer across many features (e.g. "Build the database schema for everything"). It cannot be shipped to users.

The test: can this story be deployed to production and measured for user value WITHOUT any other story being complete first? If no — it is horizontal. Slice it.

Input

Load knowledge/prd.md. Focus on Section 3 (Functional Requirements).

Step 1 — Slice Detection Pass

For each story in the PRD, check against these anti-patterns:

For each anti-pattern found, produce:

⚠️ Story [ID] — Anti-pattern detected: [type]
   Current: [current story statement]
   Problem: [why this is not a vertical slice]
   Proposed split:
     Story A: [new story — user value]
     Story B: [new story — user value]

Step 2 — BDD Acceptance Criteria

For each story (new or validated), produce the full BDD specification:

Feature: [feature name — from Epic]
  Background:
    Given [precondition that applies to all scenarios in this feature]

  Scenario: [happy path name]
    Given [specific initial context]
    When [user or system action]
    Then [observable, testable outcome]
    And [secondary outcome if needed]

  Scenario: [alternative flow]
    Given [different context]
    When [same or different action]
    Then [different outcome]

  Scenario: [failure / edge case]
    Given [context that causes failure]
    When [action]
    Then [graceful failure behaviour — never "then an error occurs"]

AI Component Scenarios (required for any story with an LLM)

Add these mandatory scenarios to every story that involves an AI component:

  Scenario: AI component latency SLO exceeded
    Given the AI component is responding slowly
    When the operation exceeds [p99 threshold from nfr.md]
    Then the user sees [specific fallback UI/message]
    And the timeout is logged with [required trace fields]

  Scenario: AI component returns low-confidence output
    Given the AI component produces output below the quality threshold
    When the confidence score is below [threshold]
    Then [fallback behaviour — not just "show error"]

  Scenario: AI component unavailable
    Given the AI provider returns a 503 or timeout
    When the user triggers the primary action
    Then [degraded mode behaviour]
    And [alerting condition is triggered]

Step 3 — Story Map

After slicing, produce a story map table written to knowledge/story-map.md:

# Story Map

## [Epic E-01 name]

| Story ID | Name | Size | Shippable | AI component | Priority |
|-|||--|--|-|
| E-01-S-01 | [name] | S | YES | none | P1 |
| E-01-S-02 | [name] | M | YES | [component] | P1 |
| E-01-S-03 | [name] | L | YES | [component] | P2 |

## Suggested Delivery Order
[Ordered list — which story delivers the most learning per unit of effort]

## Pre-work (not stories — no direct user value)
- [ ] [Technical prerequisite 1] — blocks: [story ID]
- [ ] [Technical prerequisite 2]

Sizing Guide

| Size | Definition | Typical AI-system effort | ||--|--| | XS | Single endpoint, no AI | 0.5 day | | S | Single user flow, simple AI call | 1–2 days | | M | Multi-step flow or RAG component | 3–5 days | | L | New agent integration or eval pipeline | 1–2 weeks | | XL | Too large — must be split | — |

Never accept XL as a final size. If a story is XL, run Step 1 again.

After Slicing

Offer to update knowledge/prd.md Section 3 with the refined story set. Then suggest running reviewing-requirements as the next step.

When to Use

Follow standard when to use documentation.

Prerequisites

Follow standard prerequisites documentation.

Process

Follow standard process documentation.

Best Practices

Follow standard best practices documentation.