One plan, three views โ€” a breakdown, a story map, and a requirements contract that can't drift

You keep a work breakdown, a release story map, and a spec โ€” in three places you wire together by hand. Move one card and the other two go stale, and eventually nobody trusts the top-level number.

My Architect removes the reconciling because there is nothing to reconcile: the breakdown, the story map, and the requirements are three views of one hierarchy, not three stores that have to agree.

One tree, three projections

There is a single source-of-truth hierarchy per project โ€” one flat tree of nodes. The WBS diagram, the User Story Map, and the requirements layer are all projections of that same tree, not copies of it.

The important part is that the User Story Map is a pure regenerated view, never a second data source. When you open the map, it is generated on the fly from the hierarchy โ€” backbones are one level of the tree, cards are the level below. So a "card on the map" and a "node in the breakdown" are the same object seen twice.

That is why moving things just works:

The map is fractal, so big projects stay legible

A classic story map dies at scale: fifty cards on one wall is not a plan, it's wallpaper. My Architect's User Story Map is recursive. Each altitude shows one level's worth of items โ€” you drill into an epic to see its features, drill into a feature to see its stories โ€” instead of flattening the whole project onto one grid.

The rule of thumb the view is built around: 5โ€“15 items per level, and you drill into any epic rather than scrolling past forty siblings. The map you're looking at is always the same generated projection, just scoped to the node you drilled into. Drill down, drill back up โ€” it is one tree the whole way.

Progress and release roll up at every altitude

Because the views share the tree, the numbers share it too.

So the top-level number is trustworthy for a boring reason: no human typed it. It is the roll-up of the same nodes you moved on the map.

Requirements ride the same tree

Requirements aren't a fourth silo either. The requirements layer hangs off the same nodes โ€” a requirement is attached to the node it constrains, so "the spec" and "the breakdown" point at one another by construction instead of by a spreadsheet of IDs you maintain by hand. Move or rename the node and its requirements move with it.

The aha

Drag a story into the R2 lane on the map. Watch the same node's release badge change โ€” and watch its parent's rollup shift in the breakdown tree at the same time. You didn't update two views. You moved one node, and its two other faces followed. There was nothing to reconcile because there was only ever one plan.

Pick the shape once

The tree's levels come from a preset you choose at project creation โ€” Agile, SAFe, Simple, or Custom โ€” so the hierarchy that WBS, USM, and requirements all project from matches how your team actually plans, from a single epic up to a multi-epic program. The views adapt to the preset; you don't rebuild them per methodology.

How to try it

  1. Follow getting started to sign in and create a project โ€” pick a preset and let it scaffold a starter tree and a WBS diagram.
  2. Switch the canvas from WBS to User Story Mapping, drag a story to a new column or release lane, and check the breakdown tree on the left โ€” the move, the status, and the rollup are already updated.
  3. Want an agent driving the same tree? See connecting an AI agent โ€” it reads and edits the exact model you see, so humans and agents share one version of the truth.