Templates

Jira checklist templates

49 ready-made checklists in 18 categories that ship with Checklist Flow for Jira. 5 of them install without a paid licence. Each page lists every item and which ones are required.

How to install them: Checklist Flow for Jira documentation.

• Free

  Definition of Done (software)

  For delivery teams closing a story, task, bug or sub-task. Required items cover merge to the main branch, review by another developer, updated tests passing in CI and acceptance criteria demonstrated, with docs, release notes and monitoring as optional checks.

• Free

  Definition of Ready (user story)

  For product owners and teams refining a story before sprint planning. The story must state who needs it, what and why, have testable acceptance criteria, known dependencies and a team estimate, and fit one sprint or be split.

• Free

  Bug fix verification

  For developers closing a bug. The bug must be reproduced with steps in the work item, the root cause noted, a test added that fails without the fix, and the fix verified by someone other than the author.

• Paid

  Feature flag rollout

  For teams releasing a feature behind a flag. The flag needs an owner and must default to off in production, both states are tested, internal users get it first, and rollback steps are documented before clean up.

• Paid

  API change

  For engineers adding or changing an API. The design is reviewed before build, the change stays backward compatible or ships as a new version, every new endpoint gets an auth check, and the API reference is updated.

• Free

  Code review (author and reviewer)

  For authors and reviewers on every pull request, in Author, Reviewer and Merge sections. The author self reviews for debug code and secrets, the reviewer checks logic, tests and the diff for personal data, and CI must be green.

• Paid

  Pull request ready for review

  For developers about to request a review. Before anyone is asked, the branch is up to date, the pull request is small enough for one sitting or split, tests pass locally and in CI, and the description says how to test.

• Free

  Release readiness

  For release managers making the go or no go call before a planned production release. Scope is frozen, regression tests pass on the release candidate, no blocker or critical bugs remain, and deployment and rollback plans and the release window are agreed.

• Paid

  Hotfix release

  For engineers shipping an urgent production fix. Five required items come first: confirmed impact, a fix limited to the problem, a second engineer's review, a staging test and an agreed rollback plan, then the fix is merged back to main.

• Paid

  Mobile app store release

  For mobile teams submitting an iOS or Android build. Version and build numbers are incremented, the build is tested on the oldest and newest supported OS versions, beta crash free rate is checked, and monitoring runs for 48 hours after release.

• Paid

  QA test execution

  For testers checking one story, bug or task before it moves to done. Test cases come from the acceptance criteria, the happy path and edge cases are tested, and defects are logged and linked with results recorded in the work item.

• Paid

  Regression test pass

  For QA leads approving a release candidate. The build is deployed to test, smoke tests and the automated suite pass, areas without automation get a manual checklist, and the run ends with a regression sign off recorded by the QA lead.

• Paid

  User acceptance testing sign off

  For business owners and testers confirming a change does what was asked. Scenarios are agreed with the business owner and run on realistic data, must fix items are retested, and the business owner's sign off is recorded in the work item.

• Paid

  Security review for a change

  For teams shipping a feature that touches data, access or external input. Data is classified, every new entry point gets an auth check, input is validated and output encoded, new dependencies are scanned, and a security reviewer must approve.

• Paid

  Threat modelling session

  For architects and engineers before build starts on a new design. A data flow diagram with trust boundaries is attached, threats are listed per component from spoofing to elevation of privilege and rated by likelihood and impact, and accepted risks get an owner.

• Paid

  Vulnerability remediation

  For security and engineering teams handling a reported or scanned vulnerability. It is confirmed as real, rated with a remediation deadline, affected systems and versions are listed, and the fix is verified by rescanning or retesting.

• Paid

  Data protection impact assessment (DPIA) screening

  For product teams and privacy leads deciding whether a new feature needs a full DPIA under the GDPR. Data categories, lawful basis and retention are recorded, high risk processing is screened, the DPO is consulted, and the decision and reason are written down.

• Paid

  Data subject access request

  For privacy or support staff answering a GDPR access, erasure or correction request. The receipt date is logged because the one month deadline starts there, the requester's identity is verified, systems are searched, and the response and outcome are recorded.

• Paid

  New data processor privacy check

  For privacy and procurement teams before a new vendor processes personal data. The data is listed, a data processing agreement is signed, a security assessment is completed, and data location and the transfer mechanism are confirmed.

• Paid

  Incident response

  For the on call team while a production incident is open. An incident commander and severity are set, a channel is opened, a status notice is posted, health is confirmed by monitoring, and a linked postmortem work item is created.

• Paid

  Incident postmortem

  For teams reviewing an incident after it is resolved. The write up covers a timeline from detection to resolution, quantified impact and root cause, a review meeting is held with those involved, and action items become linked work items with owners and due dates.

• Paid

  Normal change request

  For change managers handling a planned production change. Risk, implementation and rollback plans are written first, a required item stays open until Approval Flow marks the change approved, and the change window must not clash with a freeze.

• Paid

  Standard change (pre approved)

  For operators running a low risk, repeatable change. The change must match an approved standard change model, link its procedure, run inside the allowed window and be verified, with any deviation from the procedure recorded.

• Paid

  Emergency change

  For teams making an urgent change that cannot wait for the normal cycle. The linked incident or risk justifies it, a required item stays open until Approval Flow records the emergency approver's sign off, and a retrospective is scheduled within five working days.

• Paid

  Employee onboarding

  For HR, IT and hiring managers preparing a new starter. Before day one the contract, right to work documents, payroll, laptop and accounts are done; in week one, security training and tool access; then a 30 day check in.

• Paid

  Employee offboarding

  For HR and IT when someone leaves. The last day is confirmed with HR, single sign on is disabled at the agreed time, production and admin access is removed, shared passwords and API keys are rotated, and equipment is returned.

• Paid

  Contractor onboarding

  For managers bringing in an external contractor. The contract and NDA are signed, an end date is recorded, accounts are created with an expiry date matching the contract, and access is limited to the projects in scope.

• Paid

  IT access request

  For service desk staff granting access to a system. The request names the system, access level and business reason, a required item stays open until Approval Flow records the system owner's approval, and a least privilege role is chosen.

• Paid

  Periodic access review

  For system owners running a quarterly or yearly access review. The user and role list is exported, every account is confirmed or flagged, leavers and inactive accounts are removed, excess privileges are reduced, and evidence can be attached for auditors.

• Paid

  New laptop setup

  For IT teams preparing a managed laptop for a user. The device is enrolled in device management, disk encryption is on, the operating system is fully updated and endpoint protection is installed, with the asset tag recorded against the user.

• Paid

  Product marketing launch

  For product marketers coordinating a product or feature launch. Audience, message and launch date are agreed with product and engineering, the landing page and announcement post go live, the customer email is scheduled, and results are reported after two weeks.

• Paid

  Campaign launch (email or ads)

  For marketers sending an email or paid campaign. The segment is confirmed, copy is approved, links are tested and tagged with tracking parameters, the unsubscribe link and sender details are present, and the consent basis is confirmed for every recipient.

• Paid

  Blog post publishing

  For writers and editors taking a post from draft to live. Facts and quotes are checked against their sources, the text is edited to the style guide, the content owner approves, and the post is checked on the live site after publishing.

• Paid

  Video publishing

  For content teams releasing a video. The script and final cut are approved, captions are added and checked, title and description are written, music and footage licences are confirmed, and the video is published with the correct visibility.

• Paid

  Documentation page update

  For writers and engineers keeping help pages in step with the product. Affected pages are identified, content is updated to match shipped behaviour, screenshots are refreshed, and the update is published at the same time as the release.

• Paid

  Purchase request

  For staff buying software, hardware or services. Item, supplier, cost, budget line and justification are recorded, quotes are compared above the threshold, and a required item stays open until Approval Flow records the budget holder's approval.

• Paid

  New vendor onboarding

  For finance and procurement teams setting up a new supplier before the first payment. Tax details are collected, bank details are verified by calling back a known number, the contract is signed, and the vendor is created in the finance system.

• Paid

  B2B customer onboarding

  For customer success teams taking a B2B customer from signed contract to first value. It runs from the kickoff call and tenant provisioning through admin training to a first value milestone the customer confirms, then handover to account management.

• Paid

  Customer offboarding

  For account and support teams closing a departing customer's account. The cancellation date is confirmed in writing, a data export is offered, customer data is deleted at the end of the retention period, and the exit reason is recorded.

• Paid

  Service request handling

  For service desk agents handling a request from intake to closure. The request is categorised and prioritised, acknowledged within the response target, fulfilled, and the requester must confirm it is resolved, with time spent logged.

• Paid

  Incident ticket triage (service desk)

  For first line service desk agents triaging a reported disruption. Impact and urgency set the priority, the affected service and configuration item are recorded, known errors and open major incidents are checked, and the ticket goes to the right resolver group.

• Paid

  Problem record

  For problem managers removing the cause of repeating incidents. Related incidents are linked, root cause analysis is done, a permanent fix is raised, and a required item stays open until all linked work items are done in Jira.

• Paid

  Sprint planning

  For Scrum teams preparing sprint planning. The top of the backlog meets the Definition of Ready, capacity is calculated without holidays, a sprint goal is agreed, selected work fits capacity, and the sprint is started in Jira with that scope.

• Paid

  Sprint review

  For Scrum teams showing a sprint's results to stakeholders. Stakeholders are invited, a demo is prepared for each completed work item, only work meeting the Definition of Done is shown, and feedback is captured as backlog items.

• Paid

  Sprint retrospective

  For teams closing a sprint. Previous retrospective actions are reviewed first, everyone gets a chance to contribute, and the session ends with one to three improvement actions, each with an owner, added to the next sprint.

• Paid

  Backlog refinement

  For product owners and teams keeping the next two sprints ready to plan. Items are ordered by priority, acceptance criteria are written for each item discussed, items are estimated, large items are split and outdated ones closed.

• Paid

  Accessibility review (WCAG 2.2 AA)

  For designers, developers and testers checking a user interface change against common WCAG 2.2 AA requirements. Required items cover colour contrast, alt text, keyboard only use, visible focus order, labelled form fields and a screen reader test.

• Paid

  Data migration

  For teams moving data between systems. Data owners approve the mapping, a trial run on a copy of production compares record counts and checksums, a source backup is taken, and business users validate the migrated data after cutover.

• Paid

  Database schema change

  For engineers changing a production database schema. The migration script is reviewed, stays backward compatible with the running application, is tested on a production sized copy with lock and run time measured, and its rollback script is tested.