Definition of Ready: Examples and the AI Agent Version
On this page
A developer picks up “Invoice export: make it faster and also fix the dates”, reads two lines, and spends the morning asking who reported it. An AI coding agent picks up the same item and does not ask. It ships a guess, with tests that prove the guess.
A Definition of Ready is the list that stops both. This page has the definition, three examples to copy, and a rewrite clinic: one Jira story taken through four drafts, scored after each by a rule engine, until it is ready for an agent.
Short answer: a Definition of Ready is the team’s list of what a work item needs before anyone starts it: the problem in plain words, acceptance criteria, an estimate small enough for one sprint, and no open blocker. It is not in the Scrum Guide. For AI coding agents, add four lines: the repository and the file to start in, a command that passes or fails, what is out of scope, and no passwords, keys or text that gives the agent orders. GitHub, Anthropic, OpenAI and Atlassian each ask for most of these in their own docs. In our clinic below, a story typed after stand-up passed 1 of 10 checks; four rewrites took it to 10 of 10.
What a Definition of Ready is
The Agile Alliance glossary puts it this way: the team “makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration.” The benefit it names is plain: it “avoids beginning work on features that do not have clearly defined completion criteria, which usually translates into costly back-and-forth discussion or rework”.
INVEST comes from Bill Wake’s 2003 article: a good story is Independent, Negotiable, Valuable, Estimable, Small and Testable. Two of those carry most of the weight. “A good story is testable.” And small: “Stories typically represent at most a few person-weeks worth of work.”
The Scrum Guide does not define it. We searched the November 2020 edition: the phrase “Definition of Ready” appears zero times. Readiness gets one sentence:
“Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.”
So a Definition of Ready is a team agreement, not a Scrum rule. It sits next to two other lists: acceptance criteria, which belong to one item, and the Definition of Done, which every item must meet before it counts.
The rewrite clinic: one story, four drafts
The item is made up but typical. We wrote four drafts and ran each through the rule engine of Agent Ready, our Jira app, straight from its source code on 14 November 2026. The engine has no AI in it: the same text gives the same score every time. We used its Strict for agents preset, which has ten checks, and also scored the milder Balanced and Light presets.
Draft 1: as typed after stand-up (1/10)
Summary: Invoice export: make it faster and also fix the dates
Components: Billing, Reports Blocked by: FIN-12 (open) Estimate: none
Customers say the CSV export is slow and the dates look wrong in Excel.
Make it fast and user-friendly, fix the date format etc.
Staging login for testing: password=Winter2026!Nine checks fail. It has 30 words where Strict wants 40, no acceptance criteria and no estimate.
FIN-12 still blocks it. “Fast”, “user-friendly” and “etc.” are flagged as vague. The summary
joins two jobs with “and also”, across two components. No repository is named. And the password
is found and shown only as password=****. A coding agent sends the description to its model,
so that password would leave the company with it. Only “no hidden instructions” passes.
Draft 2: one job, criteria added (6/10)
Summary: Invoice CSV export writes dates Excel can read
Component: Billing Blocked by: FIN-12 (open) Estimate: 3
Customers in Germany and the US open the invoice CSV export in Excel.
Dates come out as 2026-11-03T00:00:00Z and Excel shows them as text, so
sorting and filtering by date do not work. Finance asked for this before
the December close.
Acceptance criteria:
- Dates look right in Excel
- The export is fast
- Works for all locales etc.The speed work became its own item. The password went (and was changed, since everyone who could see the item had read it). This draft is what most teams call ready, and the milder presets agree: Light gives it 4 of 4. Strict does not. “Dates look right in Excel” and “Works for all locales etc.” have nothing a test could check, and “The export is fast” says how much nobody knows. FIN-12 is still open, and there is no link and no repository.
Draft 3: testable criteria, blocker closed, spec linked (9/10)
(same summary and context)
Spec: https://acme.atlassian.net/wiki/spaces/FIN/pages/48213/Invoice+export
Acceptance criteria:
- Given an invoice dated 3 November 2026, when I export to CSV, then the
Date column holds 2026-11-03 with no time part
- The Date column header is Invoice date
- An export of 10,000 invoices finishes in under 5 seconds on staging
- Amounts keep two decimals and a dot as the separatorEach criterion now has a number, a Given/When/Then or a visible result. “Fast” became “under 5 seconds for 10,000 invoices”. FIN-12 is done. A person could start this item. An agent would still have to guess where the code lives.
Draft 4: where the code is and how to check it (10/10)
(same summary, context and spec)
Repository: acme/billing-api
Branch: main
Start in src/export/invoiceCsv.ts. Write a failing test in
test/export/invoiceCsv.test.ts first, then fix it. Run
npm test -- invoiceCsv before you finish.
Out of scope: the PDF and XLSX exports. Do not add a library.
(same acceptance criteria)The repository line passes the last check. The start file, the test command and the out-of-scope line are not checks at all. We added them because every vendor below asks for them.
What the clinic shows:
- Structure is not readiness. Draft 2 had a criteria heading, an estimate and enough words. It would pass most Definitions of Ready. It still told an agent nothing it could test.
- The missing facts were never hard. Which file, which number, which blocker: the reporter knew them all. Writing them down costs less than reviewing a pull request built on a guess.
- A score is not truth. 10 of 10 means the item has the parts. It does not mean “under 5 seconds” is the right number. A person still owns that.
What AI coding agent vendors ask of a task
We read the task-writing guidance of four agents on 14 November 2026 and lined it up. The quotes are exact.
| A ready task has | What the vendors say | Agent Ready check |
|---|---|---|
| The problem in plain words | GitHub Copilot: “A clear description of the problem to be solved or the work required.” OpenAI Codex: “Goal: What are you trying to change or build?” Rovo Dev “won’t search work items for acceptance criteria if the work item description is empty”. | Description long enough |
| What done looks like | Copilot: “Complete acceptance criteria on what a good solution looks like (for example, should there be unit tests?).” Codex: “Done when: What should be true before the task is complete, such as tests passing”. Rovo Dev wants criteria that are “Short and focused on one specific thing.” and “Written in clear, unambiguous language.” | Acceptance criteria, Clear wording |
| Where to look | Copilot: “Directions about which files need to be changed.” Codex: “Context: Which files, folders, docs, examples, or errors matter for this task?” Claude Code: “If you name the file, describe the symptom, and say what “fixed” looks like up front, you usually save yourself a round of corrections later.” | Repository known, Link |
| A check that passes or fails | Claude Code: “Give Claude something it can run that comes back pass or fail.” Codex: “Codex can do this loop for you, but only if it knows what “good” looks like.” | None: put it in the project’s brief |
| Constraints | Codex: “Constraints: What standards, architecture, safety requirements, or conventions should Codex follow?” Claude Code, on a choice between two approaches: “if you care which one it picks, say so up front.” | None: put it in the project’s brief |
| One job, not too big | Copilot keeps “Complex and broadly scoped tasks” for people. Codex says a clear prompt “helps Codex stay scoped”. | Small enough, One agent run |
| Nothing ambiguous or sensitive | Copilot keeps “Ambiguous tasks” and “Tasks involving security, personally identifiable information, authentication repercussions” for people. | Clear wording |
| No open dependency | None of the four. Mike Cohn’s example rule: “All external dependencies have been resolved”. | No open blockers |
| Text that is safe to give a model | None of the four task pages. | No passwords or keys, No hidden instructions |
Sources: GitHub Docs, “Best practices for using GitHub Copilot to work on tasks”; Anthropic, “Best practices for Claude Code”; OpenAI, Codex “Best practices”; Atlassian, “Check acceptance criteria in a code review” (Rovo Dev). Links at the end.
The four agree on four lines: the problem, done-when, where to look, and a way to check. GitHub sums up why: “it’s useful to think of the issue you assign to Copilot as a prompt.” That cuts both ways. If the work item is the prompt, everything in it goes to the model: a pasted password, and any line a customer wrote to steer the agent. No vendor’s task guide mentions either, which is why they sit in the last row.
Definition of Ready examples to copy
Three lists, from loose to strict. Each item can be answered yes or no by someone who did not write the story.
Example 1: a Scrum team, people do the work
[ ] The problem and who has it are in the description
[ ] Acceptance criteria written and agreed with the product owner
[ ] Estimated, and small enough to finish in one sprint
[ ] No open "blocked by" link
[ ] Designs or a spec linked, if the story changes a screen or an APIExample 2: a team that hands stories to coding agents
[ ] Example 1, all of it
[ ] Every criterion has a number, a "must", Given/When/Then, or what the user sees
[ ] No vague words: fast, easy, intuitive, robust, etc., as needed
[ ] One job: one component, at most 8 criteria
[ ] Repository and branch named; the file or folder to start in
[ ] The command or test that must pass
[ ] Out of scope written down
[ ] No passwords, keys or tokens; no text written to the agentExample 3: a bug for an agent
[ ] Steps to reproduce, numbered, from a clean start
[ ] Expected result and actual result, each in one sentence
[ ] Version, environment and the error text or log line
[ ] Repository and the suspected file
[ ] "Write a failing test that reproduces it first"
[ ] No customer data, passwords or keys in the steps or the logKeep a list to five to eight lines. In the 335 Definitions of Done we counted for our Definition of Done examples, the median was 6 items. Lists longer than that get ticked without being read.
A Jira description template for agent work
Paste this into the work item’s description, or into a description template if your team uses one. Each heading matches a line of Example 2.
## Context
Who hits the problem, what they see, why it matters now.
Paste the exact error or attach a screenshot.
## Spec
Link to the design, the spec or the Confluence page.
## Code
Repository: org/repo
Branch: main
Start in: path/to/file
Check: the command that must pass, e.g. npm test -- name
## Out of scope
What not to change, which libraries not to add, the approach you prefer.
## Acceptance criteria
- Given <state>, when <action>, then <result you can see or measure>
- <a number, a "must", or what the user sees>Put acceptance criteria last and as a real heading. Rovo Dev reads them from the description or from a field named “Acceptance Criteria”, “AC” or “Definition of Done”. Tools that find sections by heading stop at the next heading, so text below the criteria can be read as one more criterion. Our acceptance criteria guide has 18 examples in both formats.
Gate or guideline?
Mike Cohn’s article, second on Google for this query when we searched on 14 November 2026, argues against strict ready rules. “A definition of ready can be thought of like a gate into the iteration.” A gate stops design and code from overlapping. His fix: turn the rule into a guideline, so the team can settle small open questions during the sprint.
For people, that advice holds. A developer who meets a gap asks in the team chat. An agent usually does not. In our Rovo agents test, the runs that invented facts were the ones asked to fill slots the work item had no facts for. One turned 14 % into 15 % and quoted two people who do not exist. So split the list. Keep the human Definition of Ready a guideline. Make the agent’s version a gate: an item without criteria, a repository and a check does not go to the agent.
The work item is also only half of the context. Rules that hold for every task belong in the
repository’s AGENTS.md or CLAUDE.md. OpenAI’s advice for that file: “Keep it practical. A
short, accurate AGENTS.md is more useful than a long file full of vague rules.”
Making Jira check it
Jira itself can make a field required on a transition. That checks that something was typed, not that the criteria can be tested. For the agent version you need the text read.
Agent Ready runs the checks from the clinic on every work item, by rules,
with no AI and no Rovo credits. A project picks Light, Balanced or Strict for agents and switches
single rules on or off; the vague-word list is the team’s own. The Issue is agent-ready
workflow validator holds a transition such as Ready for agent until the item passes, and JQL
finds what is left: agentReady = "false" AND sprint in openSprints(). Its user guide puts it
simply: the same checks are a Definition of Ready for people. Where Rovo is on, its agent drafts
the missing sections from the item’s own text, and a person reads them before they are inserted.
How an agent then claims a ready item, asks questions in Jira and hands back a receipt is in our Jira MCP guide. Rules for what AI-written code must show in review are in AI contribution policies. Sizing the story is in Jira story points.
How we ran the clinic
The story and its four drafts are ours, written for this page. Each draft went through Agent
Ready’s own functions, imported from its repository at commit 243b637 (13 November 2026): the
description reader, the ten Strict checks, the password and key scanner and the hidden
instruction scanner. No Jira site was involved, nothing was written anywhere, and no model was
called. The story was typed as a Story, with no web links or attachments, so the spec link counts
only as text. No project repository mapping was set, so only a Repository: line passes that
check. The script and its output are kept with our research notes.
Sources
- Scrum Guide, November 2020: scrumguides.org, read 14 November 2026.
- Agile Alliance glossary: Definition of Ready.
- Bill Wake, 2003: INVEST in Good Stories, and SMART Tasks.
- Mike Cohn, Mountain Goat Software: Definition of Ready: what it is and why it’s dangerous.
- GitHub Docs: Best practices for using GitHub Copilot to work on tasks.
- Anthropic: Best practices for Claude Code.
- OpenAI: Codex best practices.
- Atlassian: Check acceptance criteria in a code review (Rovo Dev).
- Agent Ready: product page and user guide.
Frequently asked questions
What is the difference between the Definition of Ready and the Definition of Done?
The Definition of Ready says when a work item can be started: the team understands it, it has acceptance criteria, it is small enough and nothing blocks it. The Definition of Done says when it is finished: reviewed, tested, documented, deployed. Ready is checked before sprint planning or before an agent takes the item; Done is checked before the item counts. The Scrum Guide defines only the second.
Is the Definition of Ready part of Scrum?
No. The 2020 Scrum Guide never uses the phrase. It has one sentence about readiness: "Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event." A Definition of Ready is a practice many teams add, first described in 2008 according to the Agile Alliance glossary.
Who writes the Definition of Ready?
The team that does the work, usually with the product owner, in a refinement session or a retrospective. It is a team agreement, like the Definition of Done. Keep it to five to eight items that anyone can answer yes or no, and revise it when stories keep coming back unclear.
Should a Definition of Ready be a hard gate?
For people, usually not. Mike Cohn warns that strict ready rules turn into a stage gate and stop design and coding from overlapping; a team can settle small open questions during the sprint. For AI coding agents, yes: an agent that meets a gap tends to fill it with a guess, so an item without criteria, a repository or a way to check the work should not reach it.
Does an AI coding agent need a different Definition of Ready?
It needs the same core plus three things a person would find on their own: which repository and files to start in, a command or test that comes back pass or fail, and what is out of scope. It also needs the text to be safe to hand to a model: no passwords or keys, and nothing written to steer the agent. GitHub, Anthropic and OpenAI all ask for the first two in their own docs.
Can an AI agent write the Definition of Ready sections for me?
It can draft them, and you must check them. In our Rovo test, 2 of 7 agent runs invented facts when asked to fill criteria the work item had no facts for. Let an agent draft from the item's own text, then compare every number and name with the item before you save it.