Most teams have had this happen: a task lands in the sprint, someone picks it up, and then the work stalls because the description is unclear, the requirements are missing, or a dependency isn't sorted. The team ends up chasing the details they needed before they even started. A Definition of Ready is the agreement that stops that.
Key takeaways
- A Definition of Ready (DoR) is a short list of requirements a task needs before the team starts it — the entry checkpoint for a sprint.
- Keep it to 5–7 items the team agreed on, each tied to a real blocker.
- Put the DoR on the task, not in a separate doc. Common options: action items in the description, custom fields, or a checklist app — each with its own trade-offs.
- With a checklist app like Checklists for Jira (Templates & Automation), you can save DoR as a template, automatically add it to new tasks, and mark items as required to hold back tasks that aren't ready.
What is a Definition of Ready?
A Definition of Ready (DoR) is a short list of requirements a task should meet before the team starts working on it. It's the entry check for a sprint, the same way a Definition of Done is the exit check: the DoR says "this is clear enough to pick up," and the DoD says "this is finished." Teams usually keep it as a checklist on the task, but the point is the agreement itself — settling it once means fewer half-formed tasks reach the board.
Why use a Definition of Ready in Jira?
With a DoR in a task, planning becomes more predictable. You can't put a reliable estimate on a task that isn't clear yet, so a shared bar keeps sprint planning grounded: the work you commit to is work the team understands.
It also pays off when work comes to you from outside the team. A task from another team or a stakeholder who doesn't share your context tends to arrive with gaps, and without an agreed bar, you either start and stall or go back and forth for the basics. A Definition of Ready gives you something concrete to point to, so sending a task back isn't "this is bad," it's "here's the short list we agreed on, let's fill these in first." Over time, the incoming tasks arrive in better shape.
What goes into a Definition of Ready?
Keep a Definition of Ready for the things that actually stop someone from starting a task. A common DoR looks like this:
- The problem or user story is written clearly.
- Acceptance criteria are defined.
- Designs or mockups are attached if the work needs them.
- Dependencies on other teams are known and not blocking.
- The task is estimated by the team (story points or hours).
Every team's list will be a little different depending on their workflow. A few practical tips when you put one together:
- 5–7 items is the ceiling. A long DoR goes unread and turns into a formality.
- A DoR is a team agreement. It works best when the team writes it themselves, usually at a retro.
- Tie it to real pain. Don't add items just in case. If you keep starting tasks only to hit "no mockup," add a mockup item.
- DoR isn't the same as DoD. The DoR is what's needed to pull a task in, while the Definition of Done is what's needed to close it.
How do you set up a Definition of Ready in Jira?
The main idea is to keep the DoR where the task lives. Here are a few common ways to set it up in Jira, from quickest to most robust:
- Action items in the description. Type your DoR straight into the task description as action items. It's instant and needs no setup, so it fits tasks your own team creates. The limits: it's manual, and it doesn't help much with tasks raised by other teams, since they don’t know your criteria.
- Custom fields. You can turn each requirement into a custom field on the task so it appears on the create screen for whoever raises it. This approach works well when your DoR is a couple of specific fields. However, creating or editing custom fields needs admin rights, and conditional items like "mockups attached if the work needs them" won't fit neatly into a field.
- A checklist app from the Atlassian Marketplace. When your DoR contains different types of requirements, a checklist app lets you track them all directly on the task. You save the DoR as a template once and have it automatically added when a task is created, so the criteria are in place from the start, even for tasks raised by other teams.
To see how that automatic setup works, here's a practical example using the app our team builds, Checklists for Jira (Templates & Automation). Other checklist apps may handle this differently, so the exact setup will depend on the app you use.
Suppose your team has already agreed on its DoR criteria and wants them added automatically to every task in the project. In our app, there are two ways to set this up:
- From a saved template. Open a task, add the checklist, and save it as a template (checklist menu → Save as template). Then, in your Jira Automation rule, add the Add Checklist to work item action and select that template.
- Written with syntax. Choose this option if you want the checklist to pull details from the task itself, such as the issue key, the assignee's name, or a due date. In the same Add Checklist to work item action, choose the Custom template (manual input) option and write the checklist with its simple syntax and Jira smart values.
If your team wants the DoR to be more than a reminder, you can mark its items as required and add a workflow rule that keeps a task from moving into the sprint until they're all checked. Plenty of teams don't go that far and just use it as a shared habit during refinement. Both work.
Why a Definition of Ready is worth it
A Definition of Ready is a small habit with a real payoff: a short, shared list of requirements that keeps vague tasks off the board, so the team spends its time building instead of asking what a task even means.
Does your team use a Definition of Ready? Curious what's on your list, and whether you keep it as a habit or actually hold back tasks that aren't ready.
