Nw User Story MappingSAFE

AI agents that guide you from idea to working code, with you in control at every step.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: nw-user-story-mapping
description: User story mapping for backlog management and outcome-based prioritization. Load during Phase 2.5 (User Story Mapping) to produce story-map.md and prioritization.md.
user-invocable: false
disable-model-invocation: true
---

# User Story Mapping

Create story maps that organize user stories spatially by activity and priority, then slice releases by outcome impact. Reference: Jeff Patton, "User Story Mapping" (2014). Integrates outcome-based prioritization from Gothelf/Seiden and riskiest-assumption-first from Maurya.

## Story Map Anatomy

| Element | Position | Purpose |
|---------|----------|---------|
| **Backbone** | Top row, left-to-right | User activities in chronological order -- the spine of the journey |
| **Ribs** | Columns under each activity | User tasks broken down vertically by detail and priority |
| **Walking Skeleton** | Horizontal line across all activities | Thinnest possible end-to-end working flow. Not an MVP -- it is the minimum slice that connects ALL activities |
| **Release Slices** | Horizontal bands below skeleton | Coherent groups of stories, each adding incremental value tied to a specific outcome |

Visual structure:

```
Activity A    Activity B    Activity C    Activity D
-----------   -----------   -----------   -----------
Task A.1      Task B.1      Task C.1      Task D.1     <- Walking Skeleton
...........   ...........   ...........   ...........   <- skeleton line
Task A.2      Task B.2      Task C.2      Task D.2     <- Release 1
Task A.3      Task B.3                                  <- Release 1
              Task B.4      Task C.3      Task D.3     <- Release 2
```

## Building the Map

### Step 1: Frame the journey
Identify the user persona and their end-to-end goal. One map per persona-goal pair.

### Step 2: Map the backbone
Write the big activities left-to-right in chronological order. These are verb phrases: "Search products", "Compare options", "Complete purchase". Aim for 4-8 activities.

### Step 3: Fill the ribs
Under each activity, list the tasks that support it. Write as short action phrases (user behaviors). Place more detail and less critical tasks lower.

### Step 4: Prioritize vertically
Reorder tasks within each column: most critical at top, nice-to-have at bottom. Ask: "Which task is essential for this activity to work at all?"

### Step 5: Draw the walking skeleton
Draw a horizontal line that captures exactly one task from each activity -- the thinnest slice that delivers end-to-end flow. Every activity must be represented. If an activity has no task above the line, the skeleton is incomplete.

### Step 6: Slice into releases by outcome
Group remaining tasks into horizontal bands. Each band targets a specific outcome KPI. Name each release by the outcome it achieves, not the features it contains.

## Outcome-Based Prioritization

Prioritize releases by outcome impact, not feature completeness. Each release slice targets a specific measurable behavior change.

### Prioritization Formula

**Value** (outcome impact) x **Urgency** (time-sensitivity) / **Effort** (complexity) = **Priority Score**

Where (1-5 scale):
- **Value** (1-5) = outcome impact. 5 = moves north-star KPI significantly. 1 = marginal improvement. In Phase 2.5, estimate from discovery insights; refine in Phase 4 after outcome-kpis.md exists.
- **Urgency** (1-5) = time-sensitivity. 5 = time-critical or derisks fatal assumption. 1 = evergreen, no deadline.
- **Effort** (1-5) = complexity. 5 = many tasks, cross-cutting, unknowns. 1 = single task, well-understood.
- **Tie-breaking**: Walking Skeleton > Riskiest Assumption > Highest Value.

### Riskiest Assumption First

From Running Lean (Maurya): validate what could kill the product before optimizing what improves it.

| Priority | What to validate | Why |
|----------|-----------------|-----|
| 1st | Walking skeleton | Does the end-to-end flow work at all? |
| 2nd | Release targeting riskiest assumption | Could this assumption kill the product? |
| 3rd | Release targeting highest-value outcome | Which behavior change drives the most impact? |
| 4th+ | Remaining releases by Value x Urgency / Effort | Incremental value delivery |

### Connecting to Outcomes

Each release slice maps to the logic model chain (Gothelf/Seiden):

```
Release Slice -> Output (features built)
             -> Outcome (behavior change: [Who] [Does what] [By how much])
             -> Impact (business KPI moved)
```

## Story Map Template (story-map.md)

```markdown
# Story Map: {feature-name}

## User: {persona}
## Goal: {what they're trying to accomplish}

## Backbone

| Activity 1 | Activity 2 | Activity 3 | Activity N |
|------------|------------|------------|------------|
| Task 1.1   | Task 2.1   | Task 3.1   | Task N.1   |
| Task 1.2   | Task 2.2   | Task 3.2   |            |
|            | Task 2.3   |            |            |

---

### Walking Skeleton
{List the minimum tasks from each activity that form the thinnest end-to-end slice}

### Release 1: {outcome target}
{Tasks included, outcome KPI targeted, rationale}

### Release 2: {outcome target}
{Tasks included, outcome KPI targeted, rationale}
```

## Prioritization Template (prioritization.md)

```markdown
# Prioritization: {feature-name}

## Release Priority

| Priority | Release | Target Outcome | KPI | Rationale |
|----------|---------|---------------|-----|-----------|
| 1 | Walking Skeleton | End-to-end flow works | {KPI} | Validates core assumption |
| 2 | {name} | {outcome} | {KPI} | {why this order} |

## Backlog Suggestions

| Story | Release | Priority | Outcome Link | Dependencies |
|-------|---------|----------|-------------|--------------|
| US-01 | WS | P1 | {KPI-1} | None |
| US-02 | R1 | P2 | {KPI-2} | US-01 |

> **Note**: In Phase 2.5, stories are task-level placeholders (e.g., "Search by category").
> Story IDs (US-01) are assigned in Phase 4 (Requirements). Revisit this table after Phase 4.
```

## Anti-Patterns

| Anti

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.