Break work down
Two different things get confused constantly:
- Sub-tasks record how work breaks down.
- Relations record why work is stuck.
One is a hierarchy. The other is a web. Use the right one and your board stays readable.
Sub-tasks
Section titled “Sub-tasks”A sub-task is a full task nested under another task. It has its own number, its own status, its own assignee, and it can be found on its own.
Nesting goes six levels deep. That is far more than most teams need, and it is there so a large epic never hits a wall halfway through being written down.
Create them
Section titled “Create them”Open a task and add sub-tasks from its panel. Or select text in any description and turn it straight into a task — a checklist you wrote in a spec becomes real, tracked work without retyping it.
Rearrange them by dragging
Section titled “Rearrange them by dragging”Drag one sub-task onto another and it becomes its sub-task. While you drag, the list shows exactly where it will land — indent and all — before you let go.
A task can never end up inside itself, and dotby will not let you try.
Rename in place
Section titled “Rename in place”Hover a sub-task row, click the pencil, type. You do not open it, you do not lose your place.
Cascade
Section titled “Cascade”Changing some properties on a parent can flow down to its sub-tasks — moving an epic to a sprint, for instance, can bring its children along. You are asked; it does not happen behind your back.
The task tree
Section titled “The task tree”From any task, one click opens the whole hierarchy — from the top-level parent down to the deepest sub-task, with the task you came from highlighted.
From that tree you can:
- jump between siblings without going back to the board
- change status or assignee on any node
- add a sub-task anywhere in it
This is the answer to “where does this sit in the bigger thing?”, which is otherwise a five-click question.
Relations
Section titled “Relations”A relation is a typed link between two tasks that are not parent and child.
| Relation | Means |
|---|---|
| Blocks | This has to finish before that can start. |
| Blocked by | The reverse. Recorded automatically on the other task. |
| Duplicates | Same work, filed twice. |
| Related to | Worth knowing about, no dependency. |
Blocks and blocked by are always created as a pair. Record it once, from whichever side you are looking at, and both tasks show it.
Why relations pay off
Section titled “Why relations pay off”A blocked task with no relation looks identical to a task nobody has started. A blocked task with a relation tells you, and everyone else, exactly what to go chase.
On the timeline, a blocking relation becomes a real dependency arrow — move the blocker and the chain moves with it.
Which one do I use?
Section titled “Which one do I use?”Ask what you are recording.
| Situation | Use |
|---|---|
| “Ship checkout” needs four steps | Sub-tasks |
| The API work must land before the UI work | Relation — blocks |
| Two people filed the same bug | Relation — duplicates |
| A big feature spans two quarters | Sub-tasks, or an initiative |
| Loosely connected, no order | Relation — related to |
If you find yourself making a sub-task of something in a different project, you probably want a relation — or a mirror.
- Timeline and dependencies — relations, drawn.
- Run an initiative — when the work outgrows one project.
- Bulk actions — change many sub-tasks at once.