200apps Corpus

Appearance

Product Definition · master area

Story Mapping ​

Epics as columns. Stories as rows. Releases as horizontal slices. The artefact the trio negotiates scope on — and the picture that shows whether the first release is a usable thing or a half-built one.

Owners: PO, Trio Phase it lives in: What We Build (Volume III) The corpus principle this enacts: Resolution, not maximum — including in scope.

Where it lives in the chain ​

How to do this ​

The map's structure:

  • Columns left-to-right: Epics in the order the named person does them. Open exam → Score → Navigate → Submit → Review.
  • Within each column: stories the Epic decomposes into, top-to-bottom in priority (top = required for the activity to function).
  • Horizontal slices: releases. Release 1 is a thin horizontal cut across all Epics — the walking skeleton.

A team reading the map asks two questions:

  1. "If we ship release 1 (the top row across all Epics), can the named person do the activity end-to-end?" If no, release 1 is not a release — it's a partial implementation that doesn't yet help anyone.
  2. "Which stories are required for the prediction to be testable?" Those stories must be in release 1, regardless of "ease."

What good practice looks like ​

The story map is drawn at Epic kickoff, refined through shaping, used at every standup. A team that updates the map weekly knows where they are; a team with a six-month-old map is shipping from a fiction.

The map is the picture the trio negotiates on. Scope changes happen on the map — "we're cutting this row of stories from release 1 to release 2; the prediction still tests because…" — not in conversation that nobody can find next quarter.

A team without a story map plans by list — and lists don't show the cross-Epic shape. "We have 30 stories" doesn't tell anyone whether release 1 covers a single user activity or scatters across half-done activities.

200apps · How We Work · NWIRE

Internal corpus. Voice and structure © 200apps.