How do I make definition of ready checkable in Jira?

7 min read · Updated

A definition of ready becomes checkable when every criterion is observable on the Jira issue itself: a field that is filled or empty, a link that exists or doesn’t, an estimate that is set or missing. If a criterion needs a judgment call (“the story is clear”), it isn’t checkable yet and needs rewriting until it is.

Most teams already have a definition of ready. The problem is where it lives: on a Confluence page or a wall poster, checked by memory during planning, which in practice means not checked at all. This guide moves it onto the issue.

Why do definitions of ready fail in Jira?

They fail because nothing in the tool enforces them. Jira happily lets a one-line story with no criteria and no estimate into a sprint; the definition of ready exists only in the team’s discipline, and discipline degrades under deadline pressure, mid-sprint additions, and staff turnover. The stories that slip through are exactly the ones that turn into mid-sprint clarification threads and, two sprints later, production defects.

The failure is structural, not personal. A checklist nobody sees at the moment of decision is a checklist that doesn’t run.

What belongs in a checkable definition of ready?

Keep it to criteria you can verify by looking at the issue for ten seconds. A solid baseline for a Jira team:

  • The summary states an outcome, not a task (“Returning customer sees saved addresses at checkout” rather than “Checkout changes”).
  • The description says who wants it and why, in any format the team actually maintains.
  • Acceptance criteria exist and are testable: each one an observable outcome, not an instruction to the developer.
  • An estimate is set, which forces the sizing conversation; a story the team can’t estimate isn’t ready by definition.
  • Dependencies are linked, using Jira issue links, so “blocked by the payments migration” is visible instead of tribal knowledge.

Resist adding more. Every criterion beyond what the team will actually check weakens the ones that matter.

Where should definition of ready live in Jira?

On the issue, expressed as state the board can see. Two patterns work well. The lightweight version is a label or custom field(“ready”) that refinement sets when the criteria pass, so the backlog can be sorted by readiness. The stronger version is a workflow status: stories move from “Refinement” to “Ready for sprint” only when the definition passes, and sprint planning pulls exclusively from the ready column. The workflow version costs a Jira admin a few minutes and repays it every planning session.

Either way, publish the criteria list in the team’s Jira project sidebar or the sprint planning agenda, not just the wiki. The definition should be visible at the moment someone applies it.

How do I check readiness before sprint planning?

Run the check as a query, not a memory. A saved JQL filter finds the candidates that fail the observable criteria:

project = SHOP AND issuetype = Story AND sprint in futureSprints() AND (“Story Points” is EMPTY OR “Acceptance Criteria” is EMPTY)

Review that filter at the end of refinement, two or three days before planning, while there’s still time to fix what it catches. The queryable criteria (fields, estimates, links) get caught automatically; the judgment criteria (is the scope actually clear, are the criteria actually testable) still need eyes, which is where most teams either spend senior review time or let things through.

How does Vindex make readiness automatic?

Vindex covers the judgment half of the definition. It reads every story as it’s written or edited and scores the qualities a JQL filter can’t see: whether the scope is specific enough to build, whether the acceptance criteria are testable, whether the story is small enough to estimate, and whether hidden dependencies lurk in the text. The score and findings appear in the issue panel, so “is this ready?” has an answer on the issue itself before refinement starts. Teams that gate on it typically treat 70% as the readiness bar. You can score a few of your own stories without installing anything and see what the check would have flagged in your last sprint.

Related guides