Use the same work model across breakdowns and story maps

Use My Architect’s work breakdown and User Story Mapping views to inspect the same project hierarchy from different perspectives. A breakdown helps decompose an outcome; a story map helps discuss the work and releases. Requirements remain linked to the work they constrain.

The expected outcome is a navigable plan with consistent work identities, so a person and an agent can discuss the same item from either view.

Choose the view for the question

Use WBS when you need to understand a work item’s decomposition. Use User Story Mapping when release groupings and the arrangement of work help clarify the next slice. Drill into the relevant scope instead of flattening a large project into one wall of cards.

A node keeps its work identity when viewed elsewhere. The product catalog is a separate model of lasting capabilities; its feature IDs are not interchangeable with hierarchy-node IDs.

Make a change and check the shared item

1. Open the intended project and select a known work item.
2. Inspect its parent, release assignment, requirements, and current ownership.
3. Make an authorized change through the supported view or command.
4. Read back the same work ID and check the related view, rather than assuming a successful gesture proves persistence.

Hierarchy changes can affect descendants, requirement applicability, and review freshness. Managed ownership and transition rules still apply when a change is initiated from a visual view.

Interpret progress carefully

Hierarchy progress and release rollups describe the recorded descendants. They are useful for navigation and planning, but do not establish that requirements were verified or a release was deployed.

The epic flow separately records queued, in-progress, review, and delivered. Completed children do not deliver a managed epic. A requirements-loading error or an incomplete source should remain visible; an incomplete view must not be presented as a complete inventory.

Keep requirements and evidence connected

Link functional behavior, quality requirements, constraints, and decisions to the relevant work. Agents should use scoped context to read the full applicable manifest, including global and inherited requirements.

Keep specifications and evidence in linked documents. A diagram or progress percentage cannot replace the source explaining what was accepted and how it was checked.

Review the next release in My Architect using the hierarchy and story map. Confirm the work IDs, requirement coverage, ownership, and dependencies for the selected slice. Report recorded progress separately from verified delivery, with any source gaps and the next useful action.

Continue with project workflow or delivery verification.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.