# Subtasks and dependencies

> Break large work into subtasks, and sequence work that genuinely blocks other work.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/tasks/subtasks-and-dependencies

---
Two different tools that people often confuse:

- **Subtasks** break one piece of work into smaller pieces.
- **Dependencies** say one piece of work cannot start until another finishes.

## Subtasks

A subtask is a real task — its own assignee, dates, estimate and status — that
belongs to a parent.

Use one when a piece of the work needs to be **owned or scheduled separately**.
If it just needs ticking off, use a [checklist](https://helpdesk.orangescrum.com/guide/cloud/tasks/checklists)
instead.

- **Subtask**: "Write migration script" — someone owns it, it takes a day, it has a due date.

- **Checklist item**: "Update the changelog" — thirty seconds, same person, no scheduling.

> **Closing a parent does not close its subtasks**
>
> They stay open and keep appearing in filters and reports. Close them first, or
> from the parent's subtask list.

### How deep

One level. A subtask of a subtask means the parent should have been a
[milestone](https://helpdesk.orangescrum.com/guide/cloud/views/milestones) or an
[epic](https://helpdesk.orangescrum.com/guide/cloud/agile/epics-and-features), not a task.

## Dependencies

A dependency records that work must happen in order. The Gantt chart uses them
to shift dates when something slips, and on Premium to calculate the
[critical path](https://helpdesk.orangescrum.com/guide/cloud/views/gantt-chart#critical-path).

| Type | Meaning |
| --- | --- |
| **Blocks** | This task must finish before the other can start |
| **Blocked by** | This task cannot start until the other finishes |

### Use them sparingly

> **Over-linking makes the Gantt useless**
>
> Every dependency constrains the schedule. A plan with hundreds of them becomes
> brittle — one slipped task cascades into a redrawn timeline nobody trusts, and
> the team stops looking at it.

Record a dependency when it is a **genuine hard constraint**: the API must exist
before the client can call it. Do not record soft preferences about what people
would rather do first — that is what priority and sprint planning are for.

- **Real dependency**: "Database migration blocks API rollout." Physically true.

- **Not a dependency**: "We'd rather do the design first." That is sequencing preference — use priority.

### Cross-project dependencies

The ones that actually cause trouble are between teams. Record those explicitly:
they are exactly the constraints that surprise people, because neither team sees
the other's board.

On Premium, [programs](https://helpdesk.orangescrum.com/guide/cloud/projects/programs) surface cross-project
dependencies in one view.

## Which to use

**Big task, several people**

    Subtasks. Each person owns one.

**Sequential work, same person**

    Usually neither — one task with a checklist. Add subtasks only if the pieces
    need separate dates.

**Work spanning teams in order**

    Dependencies. The Gantt then shows the knock-on effect when something slips.

**Work spanning sprints**

    Split into separate tasks per sprint, linked by a dependency. A task that
    straddles sprints breaks velocity.

## Seeing the structure

- [Gantt chart](https://helpdesk.orangescrum.com/guide/cloud/views/gantt-chart): Dependencies as arrows, with critical path on Premium.

- [Task detail](https://helpdesk.orangescrum.com/guide/cloud/tasks/task-details): Subtasks and links on the task itself.