# Story map and example card

A flat backlog hides the journey and rewards component work. A story map lets you cut the
smallest end-to-end path that can teach you something, and example cards make its behavior
specific before anyone implements it.

Source: lesson 0042 · Shape User Stories into Vertical Slices.

---

## Blank — story map

**Backbone** (user activities across the whole journey, left to right):

| `[activity 1]` | `[activity 2]` | `[activity 3]` | `[activity 4]` | `[activity 5]` |
| --- | --- | --- | --- | --- |
| `[variation]` | `[variation]` | `[variation]` | `[variation]` | `[variation]` |
| `[variation]` | `[variation]` | `[variation]` | `[variation]` | `[variation]` |

**Release line.** Draw one line across the map. Everything above it is the first slice.
State what it proves: `[which assumption or outcome this slice tests]`.

**Manual seam.** Which uncertain automation can a person safely perform for the first cohort?
Record capacity `[cases/day]`, owner `[role]`, and removal trigger `[the evidence that
retires it]`.

**Slice quality test.** A slice is useful when it can be deployed independently, demonstrated
in user language, observed with a named measure, and used to decide what to do next. If the
demo is "the endpoint returns 200" or "the schema migrated", it is a task bundle.

**How to shrink without hollowing out:**

| Slice by | Keep | Defer |
| --- | --- | --- |
| persona or cohort | one user's whole path | other cohorts |
| business-rule variation | one complete policy case | exceptions and alternates |
| operational mode | a manual step behind a seam | automation, until there is evidence |
| quality threshold | safe pilot volume | global scale, until measured |

---

## Blank — example card

One card per rule worth arguing about. Four kinds of example, not forty.

| Field | What goes here |
| --- | --- |
| Rule | The behavior being clarified, in one sentence of domain language. |
| Happy | Given `[specific state with real values]`, when `[action]`, then `[observable result]`. |
| Boundary | The exact edge or counterexample, and the expected reason given to the user. |
| Failure | A dependency timeout, retry, conflict, or partial outcome — and what the caller may safely do. |
| Guardrail | The accessibility, security, privacy, performance, or operational case. |
| Telemetry | The event or measure that will show this behavior happening in production. |
| Open question | What the three amigos could not answer, and who will. |

Specificity matters more than Given/When/Then syntax. "Delivered 12 days ago" teaches;
"a recent order" does not.

---

## Completed — returns resolution pilot

### Story map

| Start request | Check eligibility | Choose resolution | Return parcel | Track outcome |
| --- | --- | --- | --- | --- |
| signed-in order | domestic / unopened / ≤ 30 days | refund to original method | carrier label, drop-off | status page and email |
| gift order | referred to an agent (judgment) | refund with restocking fee | QR drop-off (no printer) | SMS |
| guest order | opened / damaged, photo evidence | exchange | home collection | agent contact / appeal |
| agent-created on behalf | international | store credit | in-store drop-off | proactive delay notice |

**Release line:** the first row only.

| Slice | Scope | What it tests | Exit evidence |
| --- | --- | --- | --- |
| Pilot slice | Signed-in, domestic, unopened, ≤ 30 days, refund to original method, carrier label, status page and email. Warehouse receipt confirmed manually | A2 (do customers trust an automatic decision?) and both halves of the outcome, on 1% of eligible demand | Median resolution and contact rate for the exposed cohort against a matched control, at n ≥ 120 requests, with fraud and queue guardrails held |
| Slice 2 | Referral made first-class: an agent decision view, a four-hour referral SLA, an appeal path after a refusal, and referral-specific customer wording | A5 (will agents accept the reasons?) and risk R2 (does a referral read as a refusal?) | Override rate below 15% of referrals; contact rate inside the referred segment no worse than the accepted segment plus 10 points |
| Slice 3 | Opened and damaged items with structured photo evidence, plus the gift-order rule that A5 found | The remaining 22% of A1 — does the photo rule actually make those cases codifiable? | Automatic-decision coverage rises from 63% to at least 80% of in-scope requests with no fraud-guardrail movement |
| Deferred | Guest checkout (29% of demand; needs an identity design and a separate fraud model, decision date 15 November). Exchanges. International. Store credit. Home collection. In-store drop-off | Nothing yet — but each carries the reason it waits, so the deferral is a decision rather than an oversight | — |

**What the pilot slice is not.** It is not "the eligibility service" and it is not "the returns
database". Both could be finished without a single customer being served. The slice is narrow
in variation — one cohort, one condition, one resolution — and complete across the journey,
which is the only shape that can move the measure the frame is scored on.

**Manual seam:** warehouse receipt matching. About 40 confirmations a day, inside the clerk's
existing workload, owned by Lea, removed after 14 consecutive days with under 0.1% late
receipt events and zero mismatches.

### Example card — eligibility window and condition

| Field | Entry |
| --- | --- |
| Rule | An unopened item bought by the signed-in customer and delivered 30 days ago or less is accepted automatically. The window is evaluated on the delivery date in the store's timezone, not on the submission timestamp. |
| Happy | Given an unopened domestic item delivered 12 days ago and a signed-in purchaser, when they submit a return, then the decision is **accepted**, exactly one label intent is recorded in the same transaction, and the decision reaches the customer within 800 ms at p95. |
| Boundary | Given the same item delivered 31 days ago, then the decision is **refused** with reason code `outside_return_window`, the refusal states the delivery date it used, and an appeal path is offered. |
| Boundary | Given delivery exactly 30 days ago at 23:50 store time and submission at 00:10 the next day, then the decision is **accepted**: 30 days is inclusive and measured in whole days from the delivery date. *This example exists because the first implementation used UTC timestamps and refused it.* |
| Failure | Given an accepted return whose carrier call timed out, when the worker retries with the same client reference, then the original label is returned and no second label is created. Given the carrier unavailable for 30 minutes, then eligible requests are still accepted and 99% of pending labels are created within 15 minutes of recovery. |
| Guardrail | A keyboard-only customer can complete the happy path; every refusal reason is announced by a screen reader and never conveyed by color alone. Editing the order id in the URL to another customer's order returns 404, logs the attempt with the actor, and leaks no field of that order into any response, log line, or error message. |
| Telemetry | `eligibility_decision_total{outcome, reason_code}` and `eligibility_decision_seconds` as a histogram. A shift in the reason-code mix is the earliest signal that a policy change did something unintended. |
| Open question | Does "delivered" mean the carrier-scanned delivery or the order platform's delivery date? They differ by up to two days. **Answered:** carrier-scanned, because that is what the customer sees. |

### Example card — fraud hold

| Field | Entry |
| --- | --- |
| Rule | A customer with three or more returns marked "not received" in the trailing 90 days is **referred**, never auto-refused, and no label is created until an agent releases the hold. The customer is never shown the fraud reason. |
| Happy | Given such a customer, when they submit an eligible return, then the decision is referred with the internal reason `fraud_review`, the customer sees "a specialist is checking this — you'll hear within 4 hours", and no label intent is recorded. |
| Boundary | Given a customer whose third such return was 91 days ago, then no hold applies and the normal decision runs. |
| Failure | Given a held return still unanswered after 4 hours, then an alert routes to Nils and the aging hold appears on the operations dashboard. An unanswered hold is a customer waiting, not a queue statistic. |
| Guardrail | No customer-visible text, email, or API response distinguishes a fraud hold from any other referral. A negative test asserts that `fraud_review` never appears in any customer-facing payload. |
| Telemetry | `fraud_hold_rate` by cohort and exposure stage; `fraud_hold_age_seconds` max. Both feed the rollout guardrail, not only a dashboard. |
| Open question | None. The rule came from Risk in writing, which is what made automatic approval possible at all. |

**Traces to:** the referral outcome comes from the A1 sample in `assumption-map.md`; the
timeout and carrier-unavailable examples are the acceptance evidence for driver D1 in
`architecture-driver-table.md` and for ADR 0003; the fraud-hold telemetry is a stop threshold
in `rollout-contract.md`.