Skip to content
Software Architecture Guide

Story Mapping

Explanation

Section titled “Explanation”

A story map organizes what users do with a system. A flat backlog (one ordered list of work) hides how items relate. A story map shows how the stories fit together (f13). Its purpose is to tell one big story about the system (f6).

Building blocks

  • A task is something a person does to reach a goal (f4).
  • An activity is a bigger thing people do. Tasks are the smaller steps arranged under activities (f3).
  • Each card holds a short verb phrase, which describes one step (f7).

Backbone and ribs

The top-level items form the backbone. They hold the essential capabilities of the system, and they are not prioritized (f1). The horizontal axis shows the order of user steps, left to right (f10).

The ribs are the stories hanging below the backbone. Height signals priority. High placement means absolutely necessary. Lower placement means less necessary (f2). You build across the backbone first, then down each rib by priority (f6).

Slicing releases

The thinnest end-to-end slice is called the walking skeleton. It is built first (f5). Once the map is full of options and details, you slice it into small, successful releases (f8). Horizontal lines mark the planned releases. A good map starts from one significant objective or MVP (minimum viable product) (f11).

Building it together

Teams build maps with sticky notes and paper on a wall. Remote teams use a virtual whiteboard (f12).

What a map is not

A story map is not a precise tool like a flow chart. It relies on storytelling to convey the varied ways users use a product (f9). One practitioner compares the backbone to the macro process across users, as in kite-level use cases. They say maps only go halfway toward their goal-level approach (f14). See Use Case Goal Level.

Example

Section titled “Example”

A team builds an online bookshop map. The backbone reads, left to right: “Find a book”, “Choose a book”, “Pay”, “Receive order”. Under “Pay”, the card “Enter card details” sits high because it is necessary. “Save card for later” sits lower. The team draws a line below the top cards. Everything above it becomes the first release, a thin path from search to delivery.

Trade-offs

Section titled “Trade-offs”

A story map is imprecise by design. It communicates through storytelling, so it cannot replace a flow chart when exact process logic matters (f9). The backbone is left unprioritized. Priority is judged only on the ribs below it (f1). Cockburn’s view is that maps cover only part of the goal-level approach to use cases (f14).

Backbone of activities left to right, with ribs below; lower ribs are less necessary.

Diagram source 
flowchart LR
  A[Find a book] --> B[Choose a book] --> C[Pay] --> D[Receive order]
  A --> A1[Search by title]
  B --> B1[Add to cart]
  C --> C1[Enter card details]
  D --> D1[Track parcel]
  C1 --> C2[Save card for later]

Checks

Section titled “Checks”
  • The map’s cards are short verb phrases, each describing one user step.
  • Steps are ordered left to right, and vertical placement shows priority.
  • Releases are marked as horizontal slices, starting from one objective or MVP.
  • A thin end-to-end walking skeleton is identified as the first slice.
Section titled “Related”

Sources

Section titled “Sources”