How do I make definition of ready checkable in Azure DevOps?

A definition of ready becomes checkable the moment it exists in two places Azure Boards can show you: the Definition of done text on the board column that holds refined work, and a shared query that lists every candidate work item failing it. Written criteria plus a query that finds the failures beats any amount of process agreement.

Most teams already have the criteria written somewhere. What they don’t have is a way to tell, on the morning of sprint planning, which work items actually meet them. This guide closes that gap with the parts Azure Boards already gives you.

Why do definitions of ready quietly stop working?

Because they live somewhere nobody is standing. A definition of ready in a wiki page, a team charter, or a pinned chat message is invisible at the two moments it matters: when someone writes a work item, and when the team pulls it into a sprint. Nothing in Azure Boards points at it, so the only enforcement is whether a particular person happens to speak up.

The second failure is length. A 15-item checklist gets read once, then approximated forever. Five criteria that every team member can recite from memory will catch more bad work items than fifteen criteria nobody can list.

The third is timing. Readiness checked during sprint planning is checked too late: the meeting either stalls while someone rewrites a work item live, or the team commits anyway and discovers the gap in the third day of the sprint.

What belongs in a checkable definition of ready?

Keep it to criteria a second person can verify by reading the work item. Five is a good target:

• The outcome is clear. The title and description say who gets what and why, not which service gets touched.
• Acceptance criteria are present and testable. The Acceptance Criteria field is filled, and each line is a condition with an observable result. See writing testable acceptance criteria.
• No unresolved dependency. Anything the work item waits on is linked as a related or predecessor work item, not mentioned in a comment.
• It is sized. Story Points on a User Story, or Effort on a Product Backlog Item, is set and the team believes it. An unsizeable work item is not ready, it is unsplit.
• Open questions have a name and a date. Not “waiting on design”, but who is answering and by when.

Notice what is missing: no attachment requirements, no mandatory design links, no field ceremony. Every criterion above changes whether the work can be built this sprint. Anything that doesn’t clear that bar belongs in a style guide, not a readiness gate.

Where should the definition of ready live in Azure Boards?

Put the text in the Definition of done field on the board column where refined work sits. Open the board, choose Configure board settings → Columns, pick the column, and paste the five criteria in. Azure Boards then shows an information icon on the column header that opens the list, so the criteria are one click from the cards they govern. The field is named for done, but it is just per-column text, and readiness is exactly the kind of standard it is useful for.

Then make the state itself visible. Two options, depending on how much process change you want:

• A board column. Add a Ready column between your intake and active columns, and set a WIP limit on it. No process customization needed, and the limit keeps the ready queue from becoming a second backlog.
• A custom state. On an inherited process, add a Ready state to the User Story workflow. Heavier, but the state travels with the work item everywhere: queries, charts, exports, and the backlog view, not just one team’s board.

Either way, add a needs-refinement tag with a colour set in the board’s tag colours. Tags cost nothing, and a coloured tag on the card is the fastest readiness signal a board can carry.

How do I check readiness before sprint planning?

Save one shared query and run it the day before. In Boards → Queries → New query, build the list of sprint candidates that fail a mechanical criterion, then save it under Shared Queries so it is not living in one person’s account. A workable first version: work item type is User Story, state is not Closed or Removed, area path under your team, and Story Points is empty.

Add a second clause set for empty acceptance criteria using the Is Empty operator on the Acceptance Criteria field, and you have caught the two gaps that stall planning most often. Pin the query as a chart widget on the team dashboard and the count becomes ambient: when it climbs, refinement is behind.

Then give the check an owner and a slot. Fifteen minutes the day before planning, one person walks the query results and either fixes each work item or moves it out of the sprint candidates. The point is not the meeting, it is that readiness gets decided before the room full of people is waiting on it.

What a query can and can’t tell you

Everything above finds missing fields. It cannot tell you that a filled field is any good, and that is where the expensive work items get through: Story Points set to 5 by reflex, acceptance criteria that are three restatements of the title, descriptions that name a screen and stop.

That judgement is what Vindex automates. It reads the title, description, and Acceptance Criteria field on every work item create and update, and puts a story health score and plain-language findings on the work item form: vague scope, criteria that can’t be tested, work too large to estimate. Readiness stops being a question someone has to remember to ask.

Try it against your own backlog first. Drop a CSV export or paste one work item and see which of your ready work items score as ready. No signup, and uploads are deleted after 24 hours.