What are the three shapes of a list in Jira?
Native checkboxes in the description (and action items) are a one-off punch list on the work item. Sub-tasks are child issues with their own assignee, estimate, due date, and workflow. Checklist for Jira keeps a structured list on the parent — templates, progress, validators — without spinning up extra issues. The Jira checklists guide walks through how to add that list; this page is the decision guide.
None of them is a consolation prize. A reporter’s three verification steps belong in the description. A design pass owned by another team deserves a sub-task. Definition of Done, a QA testing checklist, and a release runbook belong on the parent as checklists so the quality bar travels with the story.
Why pick on purpose
When every “did we remember?” row becomes a sub-task, the board fills with cards that were never meant to be issues. When the quality bar lives only in Confluence, it is easy to skip. A checklist on the work item is the middle path: the same steps every time, progress on the issue and in JQL, and still one parent for the slice of work.
Using all three well is a process win. Intake stays light. Delivery keeps a shared ship bar. Real slices of work still get the dignity of a child issue. Checklist for Jira is built for the lists you repeat; Jira already handles the rest.
When to use each
Use description checkboxes for a list you will never reuse. Use a checklist when the same steps appear on every story, bug, or change — especially when you want templates, a progress bar, or a workflow gate. Open a sub-task when the work is a real slice: its own owner, estimate, and status on the board.
Put this on the work item with Checklist for Jira
Templates, automation, workflow gates, and a Rovo agent — free for teams of up to 10 users.
Side-by-side
| Need | Description checkboxes | Checklist for Jira | Sub-tasks |
|---|---|---|---|
| Ownership | Lives in the description; easy to miss in a long field | On the work item with mentions and item statuses | Own assignee on each child issue |
| Independent workflow | No | Item statuses such as Open, In Progress, Blocked, Done | Full issue workflow, status, and transitions |
| Estimates and due dates | No | Dates and mentions on items, not a full issue estimate | Story points, time, due date on the child |
| Board reporting | No | Progress on the issue, on boards, and in JQL | Each child appears as its own card |
| Lightweight progress | Manual scan of the description | Progress bar and completion count | Rollup of child issues |
| Templates | No | Project and global templates, including Protected | Issue templates only |
| Multiple lists on one parent | No | Yes — Done, QA, and release can sit together | Yes, as separate issues |
| Validation | No | Block a transition until a list (or named list) is complete | Per-issue workflow conditions |
| Automation | No | Auto-add on create or status; Jira Automation apply / complete / reset | Jira Automation on issues |
| Overhead | Lowest — typing in the description | A panel on the parent, no extra issues | A new issue for every slice |
When sub-tasks are the right tool
Create a sub-task when the work is a real slice of the job, not a quality check. A design pass owned by another team, a data-migration job with its own estimate, a security review with a separate workflow — those deserve a child issue. Checklists do not replace that. They replace the dozen “did we remember?” rows that should never have been issues.
When a checklist on the parent is the better fit
Keep Definition of Done and acceptance criteria as checklists on the story so the ship bar and the promised behavior stay visible together. Attach a QA testing checklist when testers own a pass. Use a Protected template when the wording should not drift. Auto-apply and require them with the automation guide so the process shows up without extra cards on the board.
Examples from delivery, QA, and onboarding
- Delivery: keep Definition of Done and acceptance criteria as checklists on the story. Split a performance investigation into a sub-task with its own owner.
- QA: run the QA testing checklist on the parent. Open a sub-task only when a failure needs a separate fixer and workflow.
- Onboarding: a Protected checklist on the hire ticket is enough for accounts, hardware, and intros. A sub-task is right when IT must track a laptop order as its own piece of work.
Pair it with the rest of the delivery set
When you are ready to reuse a list, start from the checklist templates and wire it with the automation guide. The Jira checklists guide covers native options and how to add a checklist. Keep sub-tasks for the work that deserves an issue; keep checklists for the process that should stay on the parent.
FAQ
Should we ban sub-tasks?
Keep sub-tasks for work that is actually a child issue — own assignee, estimate, and workflow. Use a checklist for the quality bar that should stay on the parent.
Are description checkboxes wrong?
They are the fastest home for a list you will never reuse. Graduate to a template when the same steps appear on every story.
Can one story have checklists and sub-tasks?
Yes — that is often the healthy setup. Definition of Done and QA sit on the parent. A design pass or a migration job sits beside them as a sub-task.
When should a checklist row become a sub-task?
When that row grows an owner, an estimate, and a status the board needs to show as its own card. Until then, keep it on the parent so the quality bar stays one progress bar.
Put this on the work item with Checklist for Jira
Templates, automation, workflow gates, and a Rovo agent — free for teams of up to 10 users.