Work-item model

Every piece of work on Plane follows one four-level tree. Learn the tree and anyone knows where to log work - and completion is computed by machine, not eyeballed.

The four levels

Level	What it is	Companion doc	Cycle?
EPIC	one module	1 URD	no
FEAT	a capability area of the URD (one or more related URD areas)	lives inside the URD	no
PRD	one feature	1 PRD file in the wiki	required
Task	execution: DES / BE / FE / QA	code · design · ADR	yes (while open)

EPIC (module)  ── 1 URD
  └ FEAT (capability area, one or more URD areas)   one EPIC has many FEATs
      └ PRD  ── 1 wiki file, has a code  one FEAT has many PRDs
          ├ DES
          ├ BE
          ├ FE
          └ QA                          DES/BE/FE/QA are children of the PRD

Hard rules:

• 1 EPIC = 1 URD. 1 PRD = 1 work item = 1 PRD file in the wiki (one-to-one).
• Every task must be a child of a PRD. No orphan tasks. If you don't yet know which PRD it belongs to, attach it to Intake.

Feature codes

A PRD code is always module-qualified: inventory/TKT, finance/LDG, helpdesk/TKT. The same code can exist in two different modules, so a bare PRD-LDG-001 is ambiguous.

States

A PRD item moves through three milestones:

State	Meaning
000_DRAFT	writing the spec
203_READY_TO_DEVELOP	spec locked, dev may start - the PRD stays here while its child tasks run
300_DONE	all child tasks done = feature delivered

Child tasks (DES/BE/FE/QA): each runs its own pipeline and lands at 300_DONE when its own work is done:

200_IN_PROGRESS → 205_READY_TO_DEPLOY → 210_READY_TO_TEST → 300_DONE

Note: 203_READY_TO_DEVELOP is not "done" - it only opens the gate for dev. The finish line is always 300_DONE.

When a level is "done"

Bottom-up:

Level	Done when
Task	its own definition of done → 300_DONE
PRD	every applicable child task (DES/BE/FE/QA) is 300_DONE
FEAT	every PRD under it is done
EPIC	every FEAT is done

Completion (%) in the sprint review

The report is not a single number - it's a nested table, one % per EPIC / FEAT / PRD:

• % is computed by task count, recursively bottom-up (done tasks / total tasks, excluding cancelled from the denominator).
• Do not use Plane's native progress bar (it only counts direct children, not a deep task rollup).
• Intake is excluded from % - it is a container, it has no "done".

EPIC Sale        62%
 ├ FEAT Kitchen tickets  40%
 │   ├ PRD POS & kitchen  75%  (3/4 tasks)
 │   └ PRD Kitchen station 0%  (0/3 tasks)
 └ ...

Cycles & sprints

• A PRD must have a cycle; its open child tasks also go in the current cycle (so the burndown is granular and shows a %).
• EPIC and FEAT carry no cycle - they span many sprints.
• EPIC / FEAT / PRD always have a start_date; target_date is left empty or set far out.
• Closing a sprint: transfer the incomplete PRDs + open tasks to the next cycle. This is a weekly ritual with an owner.

Intake

[PRD/ops] Intake is the shared holding bucket for any task that has no matching PRD yet. When you don't know where to log something, attach it here - never leave a task orphaned.

Intake is staging, not a home:

• Triage it weekly: whatever belongs to a feature, move it to the right PRD.
• Keep only genuinely small or recurring work that belongs to no feature (small bug fixes, config tweaks, cross-module chores).
• A task lingering in Intake is a signal that a PRD is missing - consider creating one.

Related pages

• Features & Specs (every PRD, live status) · By Month (delivery schedule) · Sprint Reviews