An acceptance criteria checklist that stays on the work item

Acceptance criteria vs Definition of Done vs ready

Definition of Done is the same on every story: tests, review, docs. Acceptance criteria change with the work — “account owner can export CSV in under five seconds.” Definition of Ready asks whether those examples exist before you start. The QA testing checklist is how you prove them. Using all three as checklists on the work item improves clarity and cuts ambiguity — status and next steps are visible without a scavenger hunt.

An example: an API that lists Jira issues

Acceptance criteria usually differ from story to story — each list describes what this work item should deliver. Picture a backlog item your team might actually pick up: build a GET endpoint that returns a paginated list of Jira issues for a project. Product wants the fields and permissions clear. Engineering wants pagination and error shapes agreed. QA wants something they can curl in a quick demo.

The checklist below is what that story might carry on the work item — not a template for every API, but a pattern: who can call it, what success looks like, what failure looks like, and how you would show it working.

The best test for each row: can someone demo this without guessing? Your next story gets its own list — same idea, different examples.

That list belongs on this story alone. In Checklist for Jira you add items like these directly on the work item, tick them as the behavior lands, and save a short starter template when the shape of your team's stories repeats — with fresh examples written each time.

Save a starter, edit per story

1. Checklist for Jira adds a checklist panel on the issue view. Add acceptance criteria there for your scenario — use the example above as a pattern and fill in rows for your work.
2. If you want a reusable scaffold, save the headings (scope, happy path, errors, demo-ready) as a project or global template, then rewrite every row when the next story starts.
3. You can configure per-template automation to add that scaffold when a Story is created or when work moves to In Progress — or apply it manually from Add → Add from template whenever you need it.
4. If your team wants strict gates on the process, add a completion validator on a workflow transition.
5. Reset or update items when scope shifts; pair with Definition of Done at the end and the QA testing checklist when testers own a pass — see the automation guide.

Pair it with the rest of the delivery set

Keep Definition of Done on the same issue for the ship bar. Attach the QA testing checklist when someone needs a structured test pass. Use Definition of Ready during refinement if intake quality helps your team. Browse the template hub for the full set.

FAQ