A Jira definition of ready checklist that works for AI coding agents

A ticket can pass every item of your Definition of Ready and still be unready. Below is a Jira definition of ready checklist that a team would sign without an argument, and a ticket that ticks every box on it. We count three decisions the ticket leaves open: the deadline, the credit and the waiting list. Whoever builds it makes them, in code, without anyone noticing.

That changes what "ready" has to mean. The usual test is whether the ticket has the right parts. The better test is whether anybody has to guess to build it. A checklist can't tell you that, because it checks what is there, and the problem is what isn't. Mike Cohn's case against strict checklists holds as long as someone answers questions in the sprint. Often nobody can. When a coding agent builds the ticket and should work through it on its own, the guesses can't wait for a question in the sprint. They have to be settled before it starts.

This page walks through that argument with one ticket. It starts without any tool, because the method works with a whiteboard and a pen. Further down we show one way to run it, and how the result arrives in Jira. We don't claim it's the only way to get a ticket ready. We think it's a good one, and we show where it holds.

The ticket passes the checklist and is still not ready

A small yoga studio has a booking app. Every booking costs one credit from the member's ten-class card. The team wants members to cancel classes themselves, and the ticket reads:

Cancel a class booking
As a member I want to cancel a booked class so that I don't pay for a class I can't attend.

Acceptance criteria:
- There is a "Cancel" button on the booking overview.
- After confirming, the booking has the status "cancelled".
- The member receives a confirmation e-mail.

3 story points. No dependencies. Design attached.

Here is the checklist we hold it against. It is built from the criteria Atlassian and Microsoft publish, which overlap heavily, plus the design line many Jira templates add. You can copy it into your own Jira template:

Definition of Ready
[x] The story says who wants what, and why
[x] Acceptance criteria are written and testable
[x] The story is estimated
[x] It is small enough for one sprint
[x] No open dependencies block it
[x] Design or mockups are attached where needed
[ ] Every business rule is decided, or listed as an open question with a default

Six boxes, six ticks. By any list on the first page of search results, this ticket is ready. The seventh line is ours. You won't find it on those pages, and the ticket fails it.

Here is what the ticket doesn't say. Until when is cancelling free, and how is that measured? Does a late cancellation give the credit back? And when a full class loses a member, does somebody move up from the waiting list? None of the three is covered by a checklist item. The acceptance criteria exist and they can be tested. They just don't answer these questions.

Those answers surface in a code review, or in a member's complaint.

The checklist has no line that could catch this, because every line asks whether something is there. Nothing on it asks what is missing.

For years that wasn't a problem worth a new line. Someone asked the question in the sprint, someone else answered it, and work went on. That is the best argument against a stricter checklist, and it deserves a fair hearing.

Cohn is right, as long as someone answers in the sprint

The Scrum Guide has no Definition of Ready. It says that backlog items a team can finish within one Sprint count as ready for selection, usually after refinement, and nothing more. Everything else is a team agreement, which is why no two lists look the same.

Mike Cohn argues that such lists do harm once they turn into gates. He pictures a bouncer at the door of the iteration, letting in only the stories that meet the rules. A rule that demands finished analysis before work may start moves the process toward stages, and a stage-gate process is waterfall by another name. It also blocks the overlap between analysis, design and coding that makes agile teams fast.

His alternative is concrete. Keep a size limit: a story much larger than about half the team's velocity stays out. Accept that dependencies on another team or a vendor are cleared first, especially if that team has been burned before. Treat everything else as a guideline, and settle open details while the sprint runs.

Xebia argues the opposite. In their picture the team is the customer of the backlog and the product owner is its supplier. A story is ready when the team can say "we get it", and the top of the backlog should hold about one and a half to two sprints of small stories like that. Their text carries a warning of its own: specify the "how" down to every detail and you are back in waterfall. The two positions disagree about the gate. Both warn that too much up-front detail leads back to waterfall.

We think both are right, in different situations. Take Cohn's case. A developer starts the ticket, hits a question at ten o'clock, asks the product owner, and has an answer by quarter past. The ticket didn't need to be perfect, because the conversation finishes it. A strict checklist would have cost more than it saved.

That works because of one condition: when the team asks, someone answers. For questions about the product's behavior, that someone is often not in the room. The cancellation deadline is a decision about the studio's business. Whether a late cancellation costs a credit is a decision about money. The product owner may have an opinion, but the decision belongs to the studio manager, and she is teaching a class until noon.

So Cohn's tolerance holds where the answer arrives within the hour. Where it doesn't, the missing decision turns into a wait.

So far this is an argument about people. Put a coding agent on the ticket and the price of the wait changes.

Stop and ask is fine. The answer comes too late.

A coding agent can stop and ask. Claude Code does it when you let it, and the right place for that is the how: which existing module to extend, which pattern the code base already uses, whether a scenario contradicts something built last month. The developer supervising the agent can answer those, or the repository can. Our advice for that class of question is the rule from How to Write a PRD for Claude Code and Cursor: if a scenario contradicts the code or another story, stop and ask. Or run the agent in plan mode first, read the plan, correct it, and only then let it write code. Both are cheap and both work.

Questions about the product's behavior are different. "Is the deadline clock time or elapsed hours?" can't be answered from the code, because the code doesn't exist yet. The developer next to the agent often can't answer it either. So they pass it on to the requirements engineer, the product owner or the business analyst, who clarify it with the customer or another stakeholder. That takes time, and nobody can say how much. The sprint tips, with or without an agent.

An agent makes the wait more expensive. The session stands still, and the momentum that made agentic coding fast goes with it. The prompt cache that keeps re-reading the agent's context cheap and quick lasts five minutes by default, one hour at its longest setting, and each use refreshes it. A question that travels through three people outlasts both. After that, the next turn processes everything the agent has read so far from scratch.

There is a second cost. Each business question the agent stops on turns the coding session into the place where the specification gets validated. That is a very frustrating and expensive place to find a gap, and the one with the fewest people who can fix it.

Others describe the same pressure from the outside. byteiota's write-up of GitHub Copilot for Jira says it has no tolerance for ambiguity: a vague ticket gets a guess instead of a fix. A Substack post on agent-ready tickets says the guesses compile and pass review. Atlassian's blog said in August that ticket quality matters more once agents do the work.

So we split the questions by who can answer them. The how goes to the developer, the agent or plan mode. The business questions go before the sprint, to the people who can answer them, while there is still time. A question that can't be answered yet doesn't have to block anything. Written down with a default and an owner, it tells the agent that the question is known and what to build until the answer comes. We keep those in an open-questions.md next to the code. That is what the seventh line of the checklist asks for.

A checklist checks what is there. Questions find what is missing.

Writing the seventh line is easy. Filling it is the work, because nobody can list decisions they haven't noticed. Something has to ask.

The oldest tool-neutral way is Example Mapping, from the BDD community and described by Cucumber. It takes about 25 minutes, a wall or a whiteboard, and four colors of cards. A yellow card holds the story. Blue cards hold its rules. Green cards hold an example for each rule. Red cards hold every question nobody in the room can answer. The cards give you the readiness signal. Many red cards mean not ready yet. Many blue cards mean too big.

Run it on the cancellation ticket and the red cards write themselves: elapsed hours or clock time, credit back or not, waiting list or not. The method turns a missing decision into a card you can see and assign. That is the difference from a checklist, which turns it into a tick.

Jira plugins take the other route. HeroCoders’ checklist can block a status transition until required items are done. ReDo scores each ticket against rules and shows the result as a percentage. Both make a list visible and checkable inside Jira. The criteria still come from the team, so they inherit the list’s blind spot: a rule nobody thought of is not on the list, and no plugin can enforce it. AI clarification steps have a similar limit. Xebia's write-up of Spec Kit notes that its clarify step finds only the ambiguity the model recognizes as ambiguity. A requirement that looks precise and hides an assumption gets through.

Speclr runs the questions as an interview. In Refinement it goes through a story rule by rule, with the other stories' rules already on the table, and every answer becomes a sentence in the spec. Here is the turn on the deadline:

Speclr: A member cancels a booking 20 hours before the class starts. Should this cancellation count as free or as late?

You: The cut-off is 24 hours. Later is late.

Speclr: Should the 24 hours be counted as elapsed hours or as clock time? On the day the clocks change, the two differ by one hour.

You: Clock time, in the studio's time zone.

The second question is the one that matters. Take a class on the Sunday the clocks go back, at 09:00. By clock time the deadline is Saturday 09:00. By elapsed hours it is Saturday 10:00, because the night has an extra hour. A member who cancels at 09:30 on Saturday is late under one rule and on time under the other. Two developers would have built two different apps, and both would have passed review.

Then the interview takes a case that wasn't on our list of three. Mia has booked all eight classes of a course. She cancels the third. Speclr asks whether this cancels only that class or the rest of the series as well. The answer, only that class, becomes a rule. It is the fourth decision, and nobody had listed it. We found it only because the interview came back to the ticket with a question instead of waiting for us to name one.

Speclr doesn't check your Definition of Ready. Readiness is what the interview leaves behind: rules that are decided, and questions that are written down with a default.

So the ticket arrives in Jira

When the interview is done, the ticket goes to Jira as a spec: the story, its rules, its data and the scenarios, in the description of one issue. This is what the cancellation ticket looks like when it arrives:

Generated by Speclr · edit in Speclr
US-031 — Cancel a class booking
Epic: Bookings | Milestone: MVP | Status: Ready

Context
As a member I want to cancel a booked class so that I don't pay for a class I can't attend.

Business rules
- BR-014  A booking can be cancelled free of charge until 24 hours before the class starts.
          The deadline is clock time in the studio's time zone, also on the day the clocks change.
- BR-015  A later cancellation is allowed. The class credit is not returned.
- BR-016  A free cancellation returns the class credit to the member immediately.
- BR-017  A freed spot goes to the first person on the waiting list, who is booked
          automatically and notified. This applies until the class starts.
- BR-018  Cancelling a booking that belongs to a course series cancels only that class.
- BR-019  A member who moves up from the waiting list pays one class credit at that moment.
          A member without a credit is skipped, and the next person on the list is offered the spot.

Actors
- ACT-002  Member: may cancel their own bookings only.

Data fields
- DF-021  booking.status: booked | cancelled | waitlisted
- DF-022  class.startsAt: UTC timestamp. studio.timeZone: IANA zone, e.g. Europe/Berlin

Non-functional requirements
- NFR-003  Cancelling twice returns the credit once.

Out of scope
- Cancelling on behalf of a member, refunds in money.

Open questions
- Q-004  Should a late cancellation return half a credit if the spot is refilled?
         Owner: studio manager. Until decided: BR-015 applies.

Below the spec, the description holds the scenarios as a code block:

Scenario: Free cancellation returns the credit
  Given Mia has booked "Yoga Flow" on Saturday at 09:00
  And it is Friday at 08:00
  When Mia cancels the booking
  Then the booking is cancelled
  And Mia's balance increases by 1 credit

Scenario: The deadline is clock time on the day the clocks change
  Given "Yoga Flow" starts on Sunday at 09:00, the day the clocks go back
  And the studio is in Europe/Berlin
  When Mia cancels on Saturday at 09:30
  Then the cancellation is late
  And Mia's credit is not returned

Scenario: A freed spot goes to the first person on the waiting list
  Given "Yoga Flow" is full
  And Noah is first on the waiting list and has at least 1 credit
  When Mia cancels her booking
  Then Noah is booked into "Yoga Flow"
  And Noah is notified
  And Noah's balance decreases by 1 credit

Scenario: Cancelling one class of a series keeps the others
  Given Mia has booked all 8 classes of the course "Yoga Basics"
  When Mia cancels the third class
  Then only that class is cancelled
  And her other 7 bookings stay unchanged

Read it against the ticket we started with. Three acceptance criteria became six rules and four scenarios. The three open decisions are answered, and the fourth, the series, is in as BR-018. One question is still open on purpose. Whether a late cancellation could return half a credit when the spot is refilled is a pricing decision for the studio manager. The spec doesn't pretend it's settled. It names an owner and a default, BR-015, so the agent builds that rule today and the question can stay open without blocking anyone. That is the seventh line of the checklist, filled in.

Developers read this in the ticket. An agent that picks the ticket up from Jira reads the same text, and there is nothing in it to guess. The export runs in one direction, like the repository export in How to Write a PRD for Claude Code and Cursor. Every generated ticket says where it came from and where to change it.

It stays incremental anyway

The objection is easy to predict. Every rule decided before the sprint sounds like waterfall, and Cohn's bouncer is back at the door.

It would be, if readiness were a property of the product. It is a property of one ticket. We never ask for the whole backlog to be specified. We ask that the next ticket someone builds is ready, and Xebia's number is a fair guide for how far ahead that has to reach: about one and a half to two sprints of small, ready stories at the top. Everything below stays rough, and rough is fine. New knowledge from the sprint, a rule the studio changes or a case a customer reports, goes into the next ticket's interview. Nothing is frozen, and nothing waits for a phase to end.

The checklist guards the exit of the backlog. By then the ticket exists, and the decisions nobody made are already folded into its text. The question we care about sits earlier, between an idea in someone's head and a ticket Jira would accept. We call that stretch the pre-backlog gap. A Definition of Ready can't see into it, because it only arrives after the ticket has been written. An interview, or an Example Mapping session, works there. They are the same move: ask before the sprint what would otherwise be found during it. The question costs a conversation now. Asked a sprint later, it costs the sprint.

Ready is what nobody who builds the ticket has to guess. A list can only show what has been ticked off. Whoever wants agents to work through a sprint on their own moves the question in front of the sprint. That isn't waterfall, as long as every ticket becomes ready on its own.

Further Reading

Your next ticket, ready before the sprint

Take your next ticket through the interview. Speclr is free for 14 days.

Get started