# Checklists

> Lightweight tick-off lists inside a task, and reusable checklist templates.

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

Source: https://helpdesk.orangescrum.com/guide/cloud/tasks/checklists

---
A checklist is a list of items inside a task. No assignee, no dates — just
things to tick. It keeps a task readable while making sure the small steps
actually happen.

## Checklist or subtask?

- **Checklist item**: Small, same person, no scheduling. "Update the changelog", "Add a regression test".

- [Subtask](https://helpdesk.orangescrum.com/guide/cloud/tasks/subtasks-and-dependencies): Needs its own owner, date or estimate.

If you would never put a due date on it, it is a checklist item.

## Adding one

Open the task and add items to the checklist section. Tick them as you go; the
task shows completion progress.

## Groups

Items can be organised into named groups, so one task can carry several distinct
lists — "Before merge", "Before release", "After deploy" — without becoming an
undifferentiated wall of ticks.

## Templates

Reusable checklists you attach to a task rather than retyping. This is where
checklists earn their keep: a definition of done, a release checklist, a code
review checklist, an onboarding sequence.

**Build from something real**

    Take the list a team already keeps in a doc or in their head and make it a
    template.

**Keep it to what gets skipped**

    A template listing the obvious steps trains people to tick without reading.
    Include the steps that actually get forgotten.

**Attach it to the task**

    Add the group from the template when you create the task.

**Revise it after incidents**

    When something is missed, that is the moment to add the item — while you
    still remember why it matters.

## Definition of done

The most valuable checklist most teams can have. Disagreement about "done" is
the single most common source of rework.

A concrete example:

- Acceptance criteria met
- Tests written and passing
- Code reviewed
- Documentation updated
- Deployed to staging and verified

> **Tip**
>
> Write it once as a template, attach it to every task, and the conversation
> stops recurring.

## Keeping them honest

**Ticking without doing**

    The failure mode of every checklist. It happens when the list is too long or
    the items are obvious. Cut it back to what genuinely gets missed — a
    five-item list people read beats a twenty-item list they tick through.

**Checklists that duplicate the workflow**

    If an item is "code reviewed" and you also have a Review status, you are
    tracking the same thing twice and they will disagree. Pick one.

**Stale templates**

    Give each template an owner. A checklist enforcing last year's process is
    worse than none.

## Where checklists show up

Checklist completion appears on the task, on
[board](https://helpdesk.orangescrum.com/guide/cloud/views/kanban-board) cards, and in progress reporting — so a
task at 8/10 is visibly nearly done without opening it.

- [Next: custom fields and statuses](https://helpdesk.orangescrum.com/guide/cloud/tasks/custom-fields-and-statuses): Shaping tasks to your own workflow.