Stanki Guild

Guide · Jira

Jira checklists vs subtasks: when to use which

Checklist Flow for Jira 3.1.1 is the production version (1 November 2026). Last updated 29 October 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

Work on one ticket has six small steps. Do you create six subtasks, or one checklist with six items? Both work, and the wrong choice costs you in board noise, estimation and the audit trail.

They solve different problems. Here is the decision table, then the details.

The decision table

#
QuestionSubtaskChecklist item
Does each step need its own assignee who sees it in their work?YesUsually not (some apps let an item name an assignee, but it is not a Jira work item)
Does each step need its own estimate?YesNo
Should each step appear on the board as a card?YesNo, the parent card carries the progress
Does each step need its own status, comments and history?YesNo, a line with a checkbox and perhaps a note
Is the work one deliverable with internal steps?NoYes
Are these the same steps on many tickets?AwkwardYes, as a template
Must the steps block the parent's transition?Yes, with the Sub-Task Blocking condition (company-managed)Yes, with a checklist app's validator

The pattern: use subtasks when a step is real work that someone plans, estimates and owns. Use a checklist when the steps are the parent's own quality or process bar: the Definition of Done, a release checklist, a code review list.

What subtasks cost you

#

Subtasks are real work items, which is both their strength and their overhead:

  • Board noise. Six subtasks means seven cards for one deliverable.
  • Estimation. Steps that were never worth estimating ("update the runbook") now sit in the hierarchy, and an unfinished subtask keeps the parent looking open after its real scope is done.
  • Indirect gating. Jira does not stop the parent moving to Done while subtasks are open unless you add a workflow rule. In company-managed workflows the built-in Sub-Task Blocking condition hides the transition until the subtasks reach chosen statuses; it applies to all of the parent's subtasks, not a chosen few.
  • Overhead per step. Creating, assigning and closing six subtasks is six trips through the create dialog.

What checklists cost you

#
  • Items are not work items. No estimate, no card on the board, no separate notification stream.
  • Native Jira has no real checklist structure. Action items (type [] in the description) cannot be marked as required, the built-in workflow validators do not read them, and Jira Automation cannot reach them (JRACLOUD-96783); there is also no checklist field type (JRACLOUD-94964). An enforced checklist therefore means an app.
  • History. Who checked which item, and when, is an app feature, not a Jira one.

Worked examples

#

Bug fix: "Checkout button does nothing in Safari". One developer, one estimate, one card. The process around the fix is a checklist (for example a bug fix verification template): reproduce first, regression test added, fix reviewed, verified on staging, release note written. No subtasks needed.

Release: "Ship billing service 2.4". Two pieces of real work with different owners become subtasks: "Migrate the database schema" (backend) and "Update the Terraform module" (infrastructure). The release readiness list stays a checklist on the parent (backup taken, feature flag plan agreed, smoke test green, announcement sent), with the critical items required before the release card can move to Done.

Both tools, each used for what it is good at.

The reporting angle

#

"Which stories reached Done with the quality steps skipped?" is a checklist question, and it is answerable only if the checklist state is searchable. Some checklist apps write their state to JQL fields; with Checklist Flow you can run checklistProgress < 100 AND statusCategory = Done. "What work remains on this epic?" is a subtask question. Decide which one your retrospectives actually ask.

The audit angle

#

If your process needs proof, look at who can change the record. Subtask status changes are in the work item history, which is solid ground. Native action items are text in a description: checking one is recorded as a description change, not as a per-item event. Apps differ here too: some keep a checklist history that an administrator can clear, others keep one that cannot be cleared from inside the app.

How our app helps

#

Checklist Flow is our app. It adds a checklist panel to Jira work items with sections, Required items, N/A, and per-item due dates, assignees and notes. The Checklist Definition of Done validator blocks the transition while a Required item is open, and fails closed if the check cannot be completed. The template library has 49 templates in 18 categories, including Release readiness and Bug fix verification, which are free; with a paid licence, templates can be applied automatically by issue type. Progress shows in a glance on the work item, the state is searchable in JQL, and every check and uncheck is kept in an append-only, hash-chained history that no role can clear in the app.

Checklist Flow is free for up to 10 users with every feature, then from USD 0.80 per user per month for the first 100 users. Without an active paid licence it still offers the same 2,000 items per work item as with a licence, 10 saved templates, the validator and the full history and export. See the documentation and the comparison with other checklist apps.

Common questions

#

Can I convert a checklist item into a subtask, or back?

Not natively in Jira. In Checklist Flow, Turn into work item on an item creates a sub-task, or another work item linked to the parent, from it, as you; with Tick this item when the work item is done on, the item is ticked when that work item reaches a Done status. Turning a sub-task back into a checklist item is not supported.

Do checklists help or hurt estimation?

Neither directly: checklist items are not estimated, and that is the point. The estimate belongs to the deliverable; the checklist is how you know the estimated work was finished properly.

Can a checklist block a transition?

Native action items cannot, because the built-in validators do not read them. A checklist app with a workflow validator can: the transition is refused while a required item is open.

When is a checklist the wrong tool?

When a step needs its own assignee who must see it in their own queue, its own estimate, its own due date visible on boards, or when another team does the step. Those are subtasks.

#