Work Item Hierarchy — Stories, Tasks, and Sub-tasks
Lifecycle OS organizes work into a clear parent-child hierarchy so your team always knows what they're building, why it matters, and how it fits together. Every item lives in a context — no orphaned tasks floating in a void.
Overview
At its core, the hierarchy breaks large pieces of work into smaller, actionable steps. The top level defines what you're building. The levels below define how you'll build it.
The hierarchy for each board type is pre-configured but can be adjusted. Custom boards offer the most flexibility — you can rename levels and choose how many levels to use.
Work items use a unique key per item (e.g., KEY-123) generated from your org key and a sequence number, making it easy to reference items across conversations, commits, and PRs.
Board Types and Their Hierarchies
Different board types use different hierarchy configurations. Lifecycle ships with presets tailored to common workflows.
R&D Boards — 3 Levels
The default for engineering teams building software.
| Level | Name | Purpose |
|---|---|---|
| 1 | Story or Bug | A feature, initiative, or defect |
| 2 | Task | Actionable work with time estimates |
| 3 | Sub-task | Granular steps within a task |
Feature Requests Boards — 1 Level (Flat)
| Level | Name | Purpose |
|---|---|---|
| 1 | Request | A single customer request, no children |
Feature Requests boards are flat by design — they're a collection point for input, not a place to plan execution. When a request is promoted to an R&D story, the hierarchy begins there.
Bugs Boards — 2 Levels
| Level | Name | Purpose |
|---|---|---|
| 1 | Bug | The reported defect |
| 2 | Task | Steps to investigate and fix it |
Customer Success Boards — 3 Levels
| Level | Name | Purpose |
|---|---|---|
| 1 | Customer | A customer account or engagement |
| 2 | CS Task | Work to be done for the customer |
| 3 | CS Sub-task | Granular steps within a CS task |
Custom Boards — Configurable
Custom boards let you define 1, 2, or 3 levels with your own labels. Use "Item", "Ticket", "Issue", "Epic" — whatever fits your team's language.
To configure levels on a Custom board: Open your board → click the gear icon → Levels tab. Here you can rename levels, add or remove levels, and configure the hierarchy depth.
Tip: If your team already has an established vocabulary ("tickets", "issues", "cards"), use Custom board type and rename the levels to match. Adoption is faster when the tool speaks your language.
Stories
Stories are the top-level unit of work in R&D boards. A story represents a feature, a user-facing capability, or a significant initiative.
- Stories are created directly on the board, not as children of anything else
- Each story has a design status — independent tracking for the design workflow running in parallel with development
- Stories aggregate hours from all their child tasks: total estimated hours and total logged hours roll up automatically
- Stories can be tagged with an Epic (a custom field) to group related stories across sprints
- Bugs at the top level behave like stories in R&D boards — they can have tasks and sub-tasks beneath them
Tasks
Tasks are the second level. They represent actionable, estimable units of work that belong to a story.
- Tasks are where time estimates live: estimated hours and QA estimated hours
- Each task belongs to a sprint and a stage (Predev, Dev, Production)
- Tasks have a QA assignee separate from the primary assignee — because the person building something shouldn't be the only one testing it
- Tasks have the full status workflow including QA statuses, deployment statuses, and blocked statuses
Tip: A good task is something one person can complete in a day or two. If a task is taking longer, break it into sub-tasks or reconsider the scope.
Sub-tasks
Sub-tasks are the third level. They break a task into smaller, trackable steps — useful for complex tasks where you want granular progress visibility.
- Sub-tasks inherit the sprint and stage from their parent task
- Sub-tasks don't have their own time estimates — hours are tracked at the task level
- Not every task needs sub-tasks. Use them when a task has distinct phases or when multiple people are contributing to a single task.
Fields Available at Each Level
| Field | Stories | Tasks | Sub-tasks |
|---|---|---|---|
| Status | Yes | Yes | Yes |
| Priority | Yes | Yes | Yes |
| Assignee | Yes | Yes | Yes |
| Custom fields | Yes | Yes | Yes |
| Design status | Yes | — | — |
| Sprint | — | Yes | — |
| Stage | — | Yes | — |
| QA assignee | — | Yes | — |
| Estimated hours | — | Yes | — |
| QA estimated hours | — | Yes | — |
Hour Aggregation
Parent items aggregate hours from all their children automatically.
- Total estimated hours: sum of all child task estimated hours + QA estimated hours
- Total logged hours: sum of all time entries logged against child tasks
This means a story gives you an at-a-glance view of the full scope of work beneath it — without any manual calculation.
Navigating the Hierarchy
In hierarchy view, stories expand into tasks, tasks expand into sub-tasks — an accordion table. Collapse what you don't need to focus on what you do.
In flat view, items are grouped by a column of your choice (status, sprint, assignee, epic, etc.). The hierarchy is de-emphasized so you can see the full picture of a sprint or status group.
Tip: Use hierarchy view during standups to walk through stories level by level. Use flat view during sprint planning to see all tasks grouped by status or assignee.