Jira checklist template

A Jira checklist template is a reusable list of items you attach to an issue every time, so the same steps get done in the same order. There are three practical ways to build one: as a set of pre-created sub-tasks (best when each item is real work with an owner and a due date), as a markdown checklist inside the description (best for lightweight, in-one-issue checks), or with a dedicated checklist app (best when you need tick-boxes that live inside a single issue). This page shows all three and gives you copy-paste checklists for release, QA, onboarding and definition of done.

How checklists actually work in Jira

Jira has no built-in checklist field. There is no native “add a checklist” button on an issue, which is why “jira checklist template” is such a common search. Teams reach the same goal three different ways, and the right one depends on what the checklist is for.

The honest framing matters here, because the three approaches are not interchangeable. A checklist that is really a list of work items, each with an owner, a due date and its own status, wants to be sub-tasks. A checklist that is a quick reminder for the person working one issue wants to be tick-boxes in the description. And if you specifically need checkbox items that stay inside a single issue and report on completion percentage, a dedicated checklist app adds that field. We do not add a checklist custom field, so the rest of this page focuses on the two approaches that work natively and are stronger for repeatable processes, and is straight with you about where a checklist app is the better tool.

Checklist as sub-tasks (the reusable, owner-driven approach)

When every item on your checklist is a real piece of work, the most powerful pattern is to template the checklist as a fixed set of sub-tasks under a parent issue. Each item becomes a sub-task with its own assignee, due date and status, so the checklist is not just a memory aid, it is tracked work that shows up on boards and in reports.

The advantage over tick-boxes is accountability. A sub-task checklist tells you who is doing each item, whether it is in progress, and when it is due. The advantage over building it by hand every time is speed and consistency: you define the list once, and it is recreated complete on every new parent.

How a sub-task checklist maps to Jira

Epic or release

The larger container the checklist belongs to, such as a release or an initiative.

Story or Task

The parent issue the checklist attaches to.

Sub-task checklist This template

Each item becomes a sub-task with its own assignee, due date and status.

A release checklist as sub-tasks:

Parent: Release <<version>>
  - Sub-task: Freeze scope and tag the release branch
  - Sub-task: Run the full regression suite
  - Sub-task: Update the changelog and release notes
  - Sub-task: Get sign-off from QA and product
  - Sub-task: Deploy to production
  - Sub-task: Verify in production and monitor for 24h
  - Sub-task: Close the release and notify stakeholders

A definition-of-done checklist as sub-tasks, attached to a story:

Parent: <<story>>
  - Sub-task: Code reviewed and merged
  - Sub-task: Unit and integration tests passing
  - Sub-task: Acceptance criteria verified
  - Sub-task: Documentation updated
  - Sub-task: Deployed to staging and smoke-tested

This definition-of-done checklist stands on its own as a reusable list of items; the pass or fail conditions that decide when a single story is finished are a different thing and belong with the acceptance criteria on a story.

Checklist inside the description (the lightweight approach)

For checks that belong to one person working one issue, a markdown-style checklist in the description is the lightest option. It needs no app and no setup, and it is perfect for things like a quick pre-merge check or a short QA pass that does not warrant tracked sub-tasks.

h2. QA checklist
* [ ] Happy path tested
* [ ] Edge cases tested
* [ ] Error states tested
* [ ] Tested on mobile
* [ ] No console errors

The trade-off is that description checklists are not tracked: they do not appear on the board, they have no owner, and Jira will not report on how many are ticked. That is fine for a personal reminder, and the wrong choice for a process you need visibility into.

When a dedicated checklist app is the right call

If what you genuinely need is checkbox items that live inside a single issue, with a completion percentage and the ability to block a transition until everything is ticked, a dedicated checklist app adds exactly that field, and it is the better fit. We are not that tool, and we would rather tell you so than pretend otherwise.

The honest distinction is simple. If you need checkbox items inside one issue, a dedicated checklist app adds that. If you need a repeatable list of work items with owners, due dates and their own status, template sub-tasks are stronger, and that is where we help. Many teams end up wanting the second thing once they look closely, because most “checklists” in a process are really steps that someone has to own.

Make the checklist reusable

A checklist only saves time if you are not rebuilding it each run. With Process Templates for Jira, you save the parent issue together with its full set of sub-tasks once, then launch the whole checklist in a click.

1. Build the checklist once as sub-tasks. Create the parent issue with one sub-task per checklist item, each with its own owner and due date.
2. Save the parent and its sub-tasks as a template. Save the whole hierarchy so the full checklist is captured once and recreates intact every time.
3. Add variables for the parts that change. Variables fill in the parts that change, such as the version number on a release checklist or the new hire’s name on an employee onboarding template, so a value typed once flows through every item.
4. Launch the whole checklist in a click. Pick the template to create the parent with its full set of sub-tasks, or have Jira Automation add the standard sub-task set when a trigger fires, for example creating the post-incident checklist automatically when an incident is resolved.

It is free for up to 10 users, needs no admin rights, and requires no scripting. To set up your first one, see the how-to guide. A post-incident checklist pairs naturally with the incident report template.

Frequently asked questions

Does Jira have checklists? Not natively. Jira has no built-in checklist field, so teams build checklists from sub-tasks, from markdown tick-boxes in the description, or with a dedicated checklist app. Each suits a different need, as covered above.

How do I make a reusable checklist in Jira? Decide whether the items are tracked work (use sub-tasks) or quick reminders (use a description checklist), build the list once, then save it as a template so it recreates on every new issue. Variables let the changing parts fill in automatically.

Sub-tasks or a checklist app, which should I use? Use sub-tasks when each item is real work that needs an owner, a due date and its own status, and when you want the checklist on your board and in reports. Use a dedicated checklist app when you need checkbox items inside a single issue with a completion percentage. They solve different problems.

Related templates

Most checklists attach to an issue you already template. Keep a story’s pass-or-fail conditions on the user story template, run a post-incident list from the incident report, or template a new hire’s first week with the onboarding Epic for new staff. Or browse the full template library for release, QA, onboarding and incident formats across software, ITSM and HR work.