What is a Definition of Ready checklist?
Definition of Ready asks whether a backlog item is clear enough to start. In Jira, a checklist turns that question into tickable steps on the work item: goal stated, acceptance criteria sketched, dependencies named, and the team aligned on size and risk. The list is the same for every story in refinement; only the ticks change.
A Definition of Ready checklist makes intake visible before work moves to In Progress. The team agrees upfront what “clear enough to start” means and tracks it on the issue — so missing designs, unknown dependencies, and vague scope surface during refinement.
Why teams keep Definition of Ready on the issue
Blocked sprint work usually traces back to intake gaps: an open question with no owner, acceptance examples still TBD, or a dependency that went unnamed until day three. A checklist on the backlog item surfaces those gaps during refinement — while the work is still easy to reorder, before coding starts.
Definition of Ready is optional — teams agree on it when intake quality is worth tracking. Keep the list if refinement gets faster; shrink it or skip it if stories pile up waiting on boxes the team skips anyway.
When to apply it
Use a Definition of Ready checklist during backlog refinement, before a story enters the sprint, or when a new item is created so intake has a home from the start. Apply it as a reminder before In Progress if your team wants a light gate — or keep it informational and let the board show what is still missing.
Definition of Ready vs Acceptance criteria vs Definition of Done
Acceptance criteria describe what this story should deliver — the examples you will demo. Definition of Ready asks whether those examples, dependencies, and sizing exist before you start. Definition of Done is the shared exit bar: tests, review, and release readiness every story owes at the end. Keep all three as separate checklists on the work item so intake, behavior, and ship quality stay distinct.
Definition of Ready — an example to start with
To build your first Definition of Ready checklist, start with the example below. Copy the list and paste it into the Checklist for Jira input field on a backlog item. Ideally, save it as a template and auto-apply it when Stories are created — that gives refinement a consistent scaffold and reuses the same headings each time. Trim rows your team skips; add ones your process needs.
Definition of Ready
- Goal and description
- User or operational problem is stated in one short paragraph
- Intended outcome is concrete and testable
- Priority and value are clear enough to rank against other work
- Scope and acceptance
- In-scope and out-of-scope are written on the work item
- Acceptance criteria exist as concrete examples, even if they will evolve
- Design or UX notes are linked, or marked N/A when design is out of scope
- Dependencies and feasibility
- Dependencies, data sources, and access are named or marked unknown with an owner
- Technical approach is feasible — spike created when sizing still needs discovery
- Risks and open questions have owners, or the item stays in refinement
- Sizing and team alignment
- A likely owner or skill set is identified
- The team has a rough estimate, story points, or a time-boxed spike
- Everyone who will work on the item understands the goal and constraints
That scaffold belongs on every story your team refines. In Checklist for Jira you add or tick items on the issue panel during grooming, save the headings as a project or global template, and auto-apply it when Stories are created — or apply it manually from Add → Add from template whenever you need it.
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.
Save a starter, automate lightly
- Checklist for Jira adds a checklist panel on the issue view. Paste the example above on a backlog item, adjust rows for your process, then save the shape as a project or global template in Checklist settings.
- Mark the template Protected if you want the step list locked while people tick items on each issue.
- Use per-template automation to attach the Definition of Ready scaffold when a Story is created — a light default so refinement always has a home. These automations are built into Checklist for Jira and run without Jira Automation credits.
- If your team wants a reminder before work starts, add a completion validator on the transition into In Progress, scoped to this template only. Keep it optional unless the team explicitly asked for a hard gate.
- Pair with acceptance criteria for the examples Definition of Ready is asking you to sketch, 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 acceptance criteria on the same issue for the promised behavior. Attach Definition of Done when work enters the sprint so the ship bar is visible from day one. Use the QA testing checklist when someone needs a structured test pass. Browse the template hub for the full set.
FAQ
Do we have to use Definition of Ready?
Definition of Ready is optional — a team working agreement Scrum leaves to you. Keep it only while it makes sprint starts clearer.
Definition of Ready versus Definition of Done?
Definition of Ready is intake before you start. Definition of Done is the shared quality bar at the end. Mixing them into one list usually hides both jobs.
How is Definition of Ready different from acceptance criteria?
Definition of Ready asks whether the examples, dependencies, and sizing exist before development. Acceptance criteria are the examples themselves — what you will demo when the story lands.
What if Definition of Ready blocks the backlog?
Shorten the list to the three or four rows your team actually uses, or drop it entirely. A heavy gate that stalls refinement defeats the purpose.
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.