Epics, subtasks and linked tickets
Tickets rarely stand alone. KAMI Tasks gives you three ways to relate them, and each answers a different question. Choosing the wrong one is not fatal, but it makes boards and reports misleading in ways that are hard to spot later.
Where: on the ticket — the Epic field, Add subtask, and Add link You need: access to the project
Which relationship, when
| You want to say | Use | It affects |
|---|---|---|
| "This is part of the payments revamp" | Epic | Board lanes, epic progress in Insights |
| "This ticket has four steps" | Subtasks | Nothing outside the ticket |
| "See also KDV-88, same area" | Linked ticket | Nothing — it is a signpost |
The test for epic versus subtask: does it need its own assignee, sprint and estimate? If yes it is a ticket in an epic. If it is a checkbox for one person doing one ticket, it is a subtask.
Epics — "what initiative is this part of?"
An epic is a ticket of type Epic that other tickets belong to. Use one per larger initiative — a feature, a migration, a client project — and put the delivering tickets inside.
- Set the Epic field on a ticket, and the epic's page lists every ticket in this epic
- On the Kanban board, tickets group into lanes by epic, so the board reads as initiatives rather than a pile
- Move a ticket into an epic from the board's right-click menu — Move to epic
- Sprint Insights tracks epic progress, which is usually the version leadership actually wants
Subtasks — "what are the steps of this ticket?"
A subtask is a child of one ticket: a step of the work, not work in its own right. Add them from the ticket with Add subtask.
Use them when one person's ticket has several checkable stages. If a subtask starts needing its own assignee and estimate, it is a ticket — make it one and put it in the same epic instead. Subtasks that are secretly tickets are invisible to sprint planning and velocity.
Linked tickets — "what else should the reader know?"
Linked tickets connect two tickets without hierarchy: a duplicate, a dependency, related work in another project. Add one with Add link.
A link is a signpost for the reader and nothing more — it does not move status, block anything, or affect any report. If you need a dependency enforced, that is a conversation and a sequence, not a link.
What Happens Next
- Setting an epic puts the ticket in that epic's lane on the board and into its progress figure in Insights.
- Subtasks appear on their parent and nowhere else — they do not get their own board card.
- Links appear on both tickets, and change nothing else.
- Moving a ticket between epics is safe and keeps everything; the ticket key never changes.
Tips
- One epic per initiative, named for the outcome. "Invoicing revamp" is findable; "Q3 work" is not.
- Do not nest structure you do not need. Epic → ticket is enough for most teams. Epic → ticket → subtask → link becomes a map nobody reads.
- Watch for epics that never close. An epic open for a year is usually a category, not an initiative — and it will distort epic-progress reporting the whole time.
- Use links generously. They cost nothing and save the next person the search.
Troubleshooting / FAQ
Q: The board shows one enormous lane. Tickets without an epic group together. Either assign epics, or turn off grouping for a flat board.
Q: A subtask is not appearing in the sprint. Subtasks belong to their parent and do not get their own sprint presence. If it needs one, it should be a ticket.
Q: I linked two tickets and nothing happened. That is correct — links are informational only.