Roadmap & Delivery
A roadmap that connects up to strategy and down to the work
Most roadmaps are a list of features detached at both ends: nothing ties a feature up to the strategy that justifies it, and nothing ties it down to the work that delivers it. So prioritisation turns into politics and scope turns into a guess. UPG types the whole span, from the need a feature addresses and the key result it drives, through epics, stories, tasks, and the cross-team dependencies between them, up to the release that ships and the roadmap theme that realises a strategic bet. Both ends of the roadmap resolve to an answer the graph already holds.
What connects a feature back to the strategy
A featurefeatureA product capability or feature carries edges in both directions. It addresses a needneedA user need, pain, desire, or constraint and a jobjobJob To Be Done: what the user is trying to accomplish, it drives a key resultkey_resultA measurable result tied to an objective, and it tests a hypothesishypothesisA testable belief about a solution. Those are typed links back into discovery and strategy, so the roadmap connects to the why behind each feature, not only the what.
That makes prioritisation legible. A feature with a clear need and a key result behind it sorts to the top; a feature with neither shows up as a candidate to cut. RICE, MoSCoW, and Now-Next-Later read as lenses over these links rather than another list to keep in sync.
featureA product capability or featureneedA user need, pain, desire, or constraintjobJob To Be Done: what the user is trying to accomplishkey_resultA measurable result tied to an objectivehypothesisA testable belief about a solutionPrioritisation becomes a property of the graph. A feature points back to the need it addresses and the key result it drives, so a feature with neither stands out as a candidate to cut. RICE, MoSCoW, and Now-Next-Later are lenses over exactly these links, not separate spreadsheets.
How a feature decomposes into shippable work
A featurefeatureA product capability or feature is decomposed into an epicepicA large body of work that can be broken into stories, an epic is specified by user storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format. nodes, and the feature also decomposes into the tasktaskA unit of work within a story or epic nodes an engineer picks up. Each level is a typed node, not a heading in a doc.
So scope is a traversal. The question of what a release contains walks epic to story to task; the question of what is left on an epic counts its open tasks. The breakdown lives in one place instead of being re-entered in a tracker that drifts from the spec.
featureA product capability or featureepicA large body of work that can be broken into stories+ acceptance_criterionuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.taskA unit of work within a story or epicA feature breaks down to the smallest unit an engineer can pick up, every level a typed node. Scope is a traversal, not a guess: ask what a release contains and the graph walks epic to story to task, with acceptance criteria attached where the work is defined.
How the graph records when a story is done
The user storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format. is the unit of agreement. An epicepicA large body of work that can be broken into stories is specified by the stories that make it concrete, and each story is verified by the acceptance criterionacceptance_criterionA condition that must be met for a story to be done nodes that say when it is done.
So “is this finished?” resolves to a checklist the graph already holds rather than a debate in review. The acceptance criteria written when the story was shaped are the same ones QA checks against, because they are the same nodes.
epicA large body of work that can be broken into storiesuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.user_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.acceptance_criterionA condition that must be met for a story to be doneacceptance_criterionA condition that must be met for a story to be doneAn epic is specified by the user stories that make it concrete, and each story is verified by the acceptance criteria that record when it is done. The definition of done is held on the graph as a list of acceptance criteria attached to the story.
How a cross-team blocker is typed on the graph
Work decomposes to the smallest pickup-able unit: a tasktaskA unit of work within a story or epic implements a user storyuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format. and has subtasks. The thing that holds it up is itself typed: a dependencydependencyA cross-team or system dependency depends on one teamteamA cross-functional team and blocks another.
So a cross-team blocker is a node with edges, visible the moment it is created. Asking what is blocked, and on which team, is a traversal rather than a round of the status meeting.
taskA unit of work within a story or epicuser_storyA structured story statement capturing a user's goal and the value they expect to receive, in the "As a… I want… So that…" format.taskA unit of work within a story or epicdependencyA cross-team or system dependencyWork decomposes to the task an engineer picks up: a task implements a story and has subtasks. A dependency between teams is itself a typed node: it depends on one team and blocks another. The cross-team blocker is recorded on the graph as a node and its two edges.
How a release records what shipped and the milestone it served
A milestonemilestoneA key date or achievement marks a moment of strategic significance and triggers the releasereleaseA shipped version of the product that meets it. The release contains the featurefeatureA product capability or feature nodes that ship together and is documented in a changelogchangelogA record of changes shipped in a release the team and customers read from the same source.
So the changelog is generated from what the release actually contains rather than written from memory at the end of the sprint. What shipped, and the milestone it served, are both one traversal away.
milestoneA key date or achievementreleaseA shipped version of the productfeatureA product capability or featurefeatureA product capability or featurechangelogA record of changes shipped in a releaseA milestone marks a moment of strategic significance and triggers the release that meets it. The release contains the features that ship together and is documented in a changelog. The features in a release and the milestone it meets are both reachable by traversing from the release node.
How a roadmap theme realises a strategic theme
A strategic themestrategic_themeA high-level strategic focus area for a planning period is realised by a roadmap themeroadmap_themeA customer problem used as the organising unit of a roadmap, which groups the featurefeatureA product capability or feature nodes that deliver it and spans the feature areafeature_areaA grouping of related features they live in. This is the edge most planning tools leave implicit.
So the roadmap is the strategy projected onto the work. Every theme on the roadmap names the strategic theme it serves, and every feature under it inherits that line of sight all the way up to the vision.
strategic_themeA high-level strategic focus area for a planning periodroadmap_themeA customer problem used as the organising unit of a roadmapfeatureA product capability or featurefeatureA product capability or featurefeature_areaA grouping of related featuresA roadmap theme connects strategy to shipped work. A strategic theme is realised by a roadmap theme, which groups the features that deliver it and spans the feature area they live in. The roadmap is a projection of the graph along these edges, not a separate list to maintain.
Delivery sits between the strategy that justifies it and the engineering that ships it. Follow a thread in either direction:
Features, epics, user stories, tasks, releases, milestones, and roadmap themes, with every property and edge.
The cascade a feature drives up into: the strategic theme a roadmap theme realises.
The services, APIs, and architecture a task turns into running software.