Everything is a story
A story without a parent epic cannot answer ‘which increment is this?’ It only answers ‘who pulled it.’
Agile product hierarchy templates
Agile product hierarchy templates for themes, epics, and stories
Agile product hierarchy templates give every increment a parent. A theme states the product bet. An epic is a slice with exclusions. A story is a testable change that serves that epic. Without the hierarchy, the board becomes a flat list and the first increment loses its edge.
For product managers and tech leads who need a copy-ready hierarchy before Sprint Planning turns every idea into a story.
A usable agile product hierarchy includes
- A theme that names the product bet, not a department
- Epics with a first-increment boundary and exclusions
- Stories that inherit a parent epic—never orphan tickets
A flat backlog is not an agile product hierarchy
Teams paste every request into stories because the tracker has a Story type. Themes and epics then become labels after the fact. Agile product hierarchy templates exist so sequencing has parents: the increment is a child of an epic, and the epic is a child of a theme. Without that, refinement invents structure under time pressure.
Epics are used as folders
An epic named ‘Portal’ will absorb every adjacent idea. A template forces a boundary and an exclusion list.
Themes are department names
‘IT’ or ‘Q3’ is not a product bet. A theme should state the user-visible change the organization is funding.
Agile Product Hierarchy Method: Fill From the Top, Then Stop at the First Increment
These agile product hierarchy templates are a sequencing aid. Complete the theme and the first epic before writing a board full of stories. Later epics can stay thin.
Hierarchy planning starts after software project intake has a complete story—the theme should not be invented from a ticket title.
The first epic’s exclusions should match what requirements gathering software already reviewed, so stories inherit a parent instead of a flat backlog.
If a story has no parent requirement, send it back through requirements gathering software before it lands on the board.
- 1
Write the theme as the product bet
One sentence for the user-visible change this body of work is buying. Not a team name and not a quarter label.
‘Staff can run client intake without a shared spreadsheet’ is a theme. ‘Digital transformation’ is not. If you cannot name the bet, you are not ready to slice epics.
- 2
Slice the first epic with exclusions
The first epic is the increment you are willing to start. Write what it will not include.
‘Staff submit a complete request and see status. Public self-service, historical import, and mobile are out.’ That sentence is the template. A folder named ‘Intake’ is not.
- 3
Create stories only under that epic
Each story names a testable change that serves the epic. Orphan stories are how the hierarchy collapses.
‘Supervisor is notified on submit’ belongs under the first epic if notification is in scope. ‘Export to warehouse’ belongs under a later epic or it does not exist yet.
- 4
Park later epics as placeholders
Name the next slices without writing their stories. Placeholders protect the first increment from absorbing them.
A second epic titled ‘Public status (later)’ with no stories is healthier than hiding that work inside the first epic’s backlog.
- 5
Add tasks only after a story is testable
Tasks are implementation crumbs. They should not become a second product hierarchy.
If a task cannot point at a story, it is either a missing story or work that does not belong in this increment.
Practical template
Agile product hierarchy template
Copy this structure into a tracker, a doc, or Foundry. If a row has no parent, you do not have a hierarchy yet. Examples use a fictional client intake change.
| Level | Template prompt | Filled example |
|---|---|---|
| Theme | What product bet is this body of work buying? | Staff can run client intake without a shared spreadsheet. |
| Epic (first increment) | What will the first slice include, and what is explicitly out? | Staff submit a complete request and see status. Out: public access, historical import, mobile app. |
| Epic (later) | What slice is named so it cannot hide inside the first epic? | Public status page (later). No stories until the first increment ships. |
| Story | What testable change serves the first epic? | A staff user submits the eight required fields and sees ‘received’ status. |
| Story | What notification or rule is in the first increment? | A supervisor is notified on submit. Client email is out of this epic. |
| Task | What implementation crumb belongs under a story—not under the epic? | Add the status column to the staff request table. |
| Exclusion (on the epic) | What will people try to sneak in that this increment refuses? | No warehouse feed. No customer-facing link. No data cleanup of last year’s files. |
Worked example
The same work as a flat list versus a hierarchy
A fictional intake change is written two ways. Only the hierarchy can tell a developer which stories belong in the first increment.
| Layer | What we wrote |
|---|---|
| Flat list | 12 stories: form, status, public link, export, mobile, cleanup, SSO, dashboard… |
| What the flat list hides | Which of those 12 is the first increment, and which are later bets |
| Theme | Staff run intake without a spreadsheet |
| First epic | Submit and see status. Public, mobile, export, and cleanup excluded |
| First stories | Required fields, received status, supervisor notification |
| Parked epics | Public status, warehouse export, historical cleanup—named, empty |
Agile product hierarchy templates succeed when a stranger can see the parent of every story and the exclusions on the first epic. A flat backlog cannot do that, no matter how tidy the titles are.
Flat backlog vs. a hierarchy template
| Flat list of stories | Theme → epic → stories |
|---|---|
| 12 equal tickets: form, status, public link, export, mobile… | Theme: staff run intake without a spreadsheet |
| No first increment—every story looks equally due | First epic: submit and see status; public and mobile excluded |
| An orphan “add export” story with no parent | Stories inherit the parent epic and its exclusions |
| Later bets look like this sprint | Parked epics named and empty: public status, warehouse, cleanup |
Hierarchy habits that collapse back into a list
Using the epic as a catch-all label
If every story can be dragged into ‘Phase 1,’ you have a folder. Rewrite the epic with a boundary and exclusions.
Writing stories before the first epic exists
Stories invented first will define the increment by volume. The template order is theme → first epic → stories.
Creating a theme per stakeholder
A theme per director is politics, not a product hierarchy. One bet, then slices.
Promoting tasks to stories to look busy
Implementation crumbs are not increments. If the user cannot tell the change happened, it is still a task.
In Precision Foundry
How Precision Foundry keeps the hierarchy attached to the plan
Precision Foundry turns reviewed requirements into sequenced epics and a first increment. Stories stay children of that increment. The hierarchy is the readiness map—not a set of labels added after the board fills up.
- The first increment and its exclusions are written before stories multiply
- Later epics can exist as placeholders without leaking into the first slice
- Stories remain attached to the reviewed answers that justified them
- The board runs the first epic; it does not invent a new hierarchy
Common questions
Questions about agile product hierarchy templates
What belongs in agile product hierarchy templates?+
A theme that names the product bet, a first epic with inclusions and exclusions, later epics as placeholders, stories that serve the first epic, and tasks that serve a story. If a story has no parent epic, the template is not in use.
How many levels should an agile product hierarchy have?+
Four is enough for most software teams: theme, epic, story, task. Initiatives can sit above themes in a large portfolio. More levels usually mean the team is encoding org charts, not increments.
Should every epic have stories on day one?+
No. Only the first increment needs stories before the board opens. Later epics should be named so they cannot hide inside the first epic. Writing all stories up front recreates a flat backlog with extra labels.
How do these templates differ from a work-breakdown structure?+
A WBS decomposes deliverables for a schedule. An agile product hierarchy sequences increments a team can finish and test. The useful artifact is the first epic’s exclusion list, not a complete tree of every future task.
Try Agile product hierarchy templates on one real request
Precision Foundry keeps this guide attached to the request so the template does not live in a forgotten doc.
Join the private alpha waitlist