Problem
Seed’s current Stories collection contains valuable Activities, User Tasks, User Stories, flows, and acceptance criteria, but it is not yet a unified story-mapping system. Product intent, journey structure, release slices, implementation work, provenance, and status are difficult to inspect together.
We need a Seed-native system that keeps the user journey central while connecting it to delivery. It must distinguish user-facing behavior from the engineering, design, research, quality, documentation, security, data, architecture, and operational work required to deliver it.
Existing records are valuable historical sources. They must never be deleted, moved, renamed, overwritten, or silently repaired by this project.
Goal
Create a durable User Story Maps system for Seed that provides:
A product-level portfolio map for Seed.
Separate journey maps beneath the portfolio.
A shared ontology and versioned HM schema family.
Standalone typed User Stories, Release Slices, and Delivery Work Items.
Embedded Actors, Goals, User Activities, and User Tasks with stable local identities.
Computed registries that list every embedded object without duplicating canonical data.
A reviewable, provenance-preserving migration from the existing Stories tree and explicitly linked records.
A visual mapping tool, beginning with a thin prototype and progressing to a durable implementation after schema validation.
Product principles
User work before implementation work. User Activities and User Tasks describe the journey; User Stories describe observable product behavior; Delivery Work Items describe the work needed to realize or validate it.
Hybrid identity model. Map-specific objects remain embedded but receive stable local IDs. Independently managed objects become standalone Seed documents.
One committed allocation at a time. A User Story has at most one committed Release Slice allocation, while proposed alternatives may remain non-committed.
Computed registries, not copies. Registry views index embedded Actors, Goals, Activities, and User Tasks and open their owning maps.
Traceability by default. Every migrated record retains exact source document, source version, source block or local context when available, extraction rationale, and review status.
Non-destructive migration. New canonical records are created alongside their sources. Existing documents remain unchanged.
Writer-governed collaboration. Records live in the Develop Seed space and follow its writer permissions.
Ontology
Core concepts
Concept | Meaning | Representation |
|---|---|---|
Product Portfolio Map | The product-wide view of Seed’s journeys and strategic slices | Standalone typed document |
Journey Map | A coherent user journey within the product | Standalone typed document |
Actor | A person or role whose work is mapped | Embedded stable-ID object initially |
Goal | An outcome sought by an Actor or the product | Embedded stable-ID object initially |
User Activity | A broad stage of the user journey | Embedded stable-ID object initially |
User Task | An action the user performs within an Activity | Embedded stable-ID object initially |
User Story | Observable product behavior supporting a User Task | Standalone typed document |
Release Slice | A coherent end-to-end set of User Stories that tests an outcome | Standalone typed document |
Delivery Work Item | Work required to realize or validate one or more User Stories | Standalone typed document |
Technical Task | A typed subtype of Delivery Work Item | Standalone typed document |
Evidence | Research, feedback, observation, or source material supporting an item | Embedded reference or standalone document when independently managed |
Migration Manifest | Reviewable classification and provenance record for proposed migrations | Standalone typed document and entries |
Delivery Work Item subtypes
Product design, user research, engineering, technical task, architecture, data, quality, security, documentation, and operations.
Principal relationships
Seed Product Portfolio Map
└── Journey Map
├── Actor
├── Goal
└── User Activity
└── User Task
└── User Story
└── Delivery Work Item
Release Slice → selects User Stories
Delivery Work Item → supports one or more User Stories
Migration Manifest Entry → proposes a new record and points to exact sources
Registry View → indexes embedded objects without copying themTarget document hierarchy
/user-story-maps
├── ontology
├── schemas
├── portfolio
├── maps
├── stories
├── releases
├── delivery-work
├── migration
└── registriesThe root collection will explain the system and link to every type and registry. All new records will be created under this hierarchy in the Develop Seed space.
Migration scope
The first migration pass begins with the complete /design/stories tree, including its seven Activity areas and their descendants. It then searches Projects, Tasks, Issues, Product, and Design for records explicitly linked to those sources.
The extraction model is an informed hypothesis rather than an automatic truth:
top-level story directories are candidate User Activities or Journey Maps;
UT-* headings are candidate User Tasks;
child story documents are candidate standalone User Stories;
delivery records explicitly linked to a story are candidate Delivery Work Items.
Every candidate is recorded in a migration manifest before canonical records are published. Similar records are compared closely: uncertain duplicates remain separate until reviewed, and subtle non-overlapping behavior is preserved.
Phases
Phase 1 — Foundation and inventory
Freeze the agreed vocabulary, invariants, status sets, reference forms, and provenance requirements.
Inventory the complete Stories tree and its schema bindings without modifying it.
Record source document IDs, versions, paths, block context, and explicit links.
Identify associated records in Projects, Tasks, Issues, Product, and Design.
Deliverables: source inventory, terminology document, invariants, and migration boundary report.
Phase 2 — Ontology and relationship model
Publish the ontology for portfolio maps, journey maps, embedded objects, User Stories, Release Slices, Delivery Work Items, evidence, dependencies, and migration records.
Define Technical Task as a Delivery Work Item subtype.
Specify stable local identity and later promotion of embedded objects to standalone records.
Specify committed and proposed release allocation semantics.
Deliverables: ontology document, relationship matrix, lifecycle rules, and examples.
Phase 3 — Versioned HM schemas
Define HM schemas for every standalone record type and embedded object shape.
Add validation rules for references, statuses, ownership, provenance, ordering, and committed allocations.
Publish representative valid and invalid fixtures.
Validate schema evolution and compatibility strategy before bulk creation.
Deliverables: versioned schema family, validation report, fixtures, and schema migration policy.
Phase 4 — Root collections and registries
Publish the /user-story-maps hierarchy and typed collection documents.
Build computed registries for Actors, Goals, Activities, and User Tasks.
Ensure each registry item resolves to its owning map and stable local ID.
Add indexes for User Stories, releases, delivery work, migration status, and review queues.
Deliverables: collection hierarchy, registry definitions, and navigation model.
Phase 5 — Reviewable migration manifest
Classify every source candidate without altering source records.
Preserve exact provenance, confidence, proposed canonical type, duplicate candidates, and classification rationale.
Mark uncertain classifications and possible merges for human review.
Review subtle differences before considering any records duplicates.
Deliverables: complete migration manifest, duplicate review queue, unresolved classification queue, and coverage report.
Phase 6 — Canonical record creation
Publish approved Journey Maps, User Stories, Release Slices, and Delivery Work Items.
Embed Actors, Goals, Activities, and User Tasks with stable local IDs.
Link every new record back to its exact source and manifest entry.
Retain all original records unchanged.
Deliverables: Seed portfolio map, journey maps, typed canonical records, provenance links, and migration audit report.
Phase 7 — Thin interactive prototype
Build a narrow visual page over validated records.
Support journey navigation, backbone ordering, User Story placement, release slicing, and linked delivery work.
Make registries searchable and open edits in the canonical owner document.
Test real create, read, update, and reopen flows with Develop Seed writers.
Deliverables: working prototype, interaction findings, access verification, and schema feedback.
Phase 8 — Durable implementation
Incorporate prototype findings without breaking canonical records.
Add robust editing, ordering, filtering, review queues, dependency display, and release allocation controls.
Handle concurrent edits, stale references, validation errors, and promotion of embedded objects.
Add performance and accessibility tests.
Deliverables: durable tool, operational documentation, tests, and rollout plan.
Phase 9 — Governance and rollout
Define review ownership, schema change procedure, migration completion rules, and archive semantics.
Train contributors on vocabulary and non-destructive migration.
Track completeness, unresolved duplicates, unallocated stories, unsupported dependencies, and stale provenance.
Decide when the new map becomes the operational planning view while preserving historical sources.
Deliverables: governance guide, contributor guide, rollout checklist, and health metrics.
Acceptance criteria
The project is complete when:
The portfolio and journey maps are navigable in Seed.
The shared ontology and schemas validate all canonical records.
Actors, Goals, Activities, and User Tasks have stable identities and appear in computed registries.
User Stories, Release Slices, and Delivery Work Items are independently addressable and discussable.
Technical Tasks are represented as a Delivery Work Item subtype rather than user-facing stories.
A User Story cannot have more than one committed release allocation.
Every migrated record links to exact provenance and a reviewed migration decision.
No pre-existing record has been deleted, moved, renamed, overwritten, or silently repaired.
Potential duplicates are reviewed for behavioral differences before merge decisions.
Develop Seed writers can create, edit, save, reopen, and navigate records through the tool.
The visual tool works against published schema-valid Seed data rather than browser-local canonical data.
Governance and schema evolution procedures are published.
Risks and safeguards
False duplicate merges: keep uncertain records separate and require review of behavior and acceptance criteria.
Ontology drift: version schemas and record migration decisions explicitly.
Too many tiny documents: keep map-local concepts embedded until sharing or independent governance justifies promotion.
Broken provenance: require source ID, version, and context on every migrated candidate.
Prototype becoming canonical too early: validate schemas first and treat the prototype as a learning surface.
Accidental source mutation: migration operations are create-only; source writes, moves, deletes, and repairs are outside project scope.
Registry divergence: derive registries from canonical maps instead of maintaining copied lists.
Permission mismatch: verify create, update, and reopen behavior as an intended Develop Seed writer before rollout.
References and provenance
Story-mapping method
Jeff Patton — User Story Mapping was the primary external introduction. It grounds the proposal in modeling the user’s journey, keeping users and their work central, and organizing stories into a map rather than a context-free list.
Jeff Patton — The New User Story Backlog Is a Map informed the distinction between the journey backbone and detailed stories, the emphasis on maintaining the product’s whole context, and release planning by slicing across the map.
Jeff Patton — How You Slice It (PDF) is the earlier article linked by Patton as the precursor to story mapping and the source context for coherent release slicing.
Jeff Patton — User Story Mapping book is the fuller published treatment referenced from Patton’s own overview. The plan did not reproduce the book; it used Patton’s public overview and original article directly.
Existing Develop Seed source material
Stories is the primary migration baseline. Its current hierarchy, seven activity areas, UT-* headings, child stories, flows, and acceptance criteria shaped the extraction hypothesis and migration scope.
Activity definition and schema supplied the existing local definition of an Activity as a high-level goal or journey phase forming the map backbone.
Projects supplied the Project document conventions, inherited owner/status schema, and workflow status used by this proposal.
Seed and Hypermedia architecture
Hypermedia Schemas informed the proposal for versioned, linked type definitions over content-addressed data.
Typed Documents informed the use of schemaDefinition, attributesSchema, and childAttributesSchema, including inherited child schemas and advisory validation.
Hypermedia Schemas in One Page was used as the compact reference for schema composition, references, validation, and document bindings.
Collaborative design decisions
The following are project-specific design decisions developed through discussion with @Untitled Contact and @Untitled Contact, not claims taken verbatim from a single external source:
the product-level portfolio map with separate journey maps;
the hybrid model of standalone User Stories, Release Slices, and Delivery Work Items plus embedded stable-ID Actors, Goals, Activities, and User Tasks;
computed registries for embedded objects;
DeliveryWorkItem as the common class, with Technical Task as one subtype;
one committed release allocation per User Story;
the reviewable migration manifest, close duplicate review, and strict non-destructive migration rule;
the nine-phase implementation plan and the thin-prototype-before-durable-implementation sequence.
Collaboration
This project plan and ontology were developed in collaboration with @Untitled Contact and @Untitled Contact.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime