There are two places AC can go — only one of them counts
An Azure DevOps User Story has a dedicated Acceptance Criteria field, separate from its Description. Both hold rich text, and to a human reader criteria in either place look equally valid. To tooling, they are worlds apart.
The Description is a free-text narrative field. The AcceptanceCriteria field is a distinct, machine-addressable field. A tool, a report, or a done-criteria rule can check whether that specific field is populated and get a deterministic answer. It cannot look at a paragraph of Description prose and reliably decide "this sentence is an acceptance criterion and that one is context." So criteria written into the Description are, for every practical automated purpose, invisible.
Why this is the AC insight most orgs miss
Ask a delivery lead whether their teams write acceptance criteria and the answer is usually a confident yes. And they're often right — the criteria exist. But because so many teams put them in the Description out of habit, the dedicated-field rate is frequently very low even in orgs that genuinely believe they have solid AC discipline.
That gap is the whole problem. Everything downstream — reporting on definition-of-done coverage, automated quality gates, portfolio quality scans — reads the field, not the prose. If the field is empty, the org is flying blind on its own quality no matter how well-written the buried criteria are.
| Measurement | What it counts | Tooling can act? |
|---|---|---|
| Strict (dedicated field) | AC present in the AcceptanceCriteria field | Yes |
| Heuristic (anywhere) | AC appearing anywhere, incl. Description | No |
The distance between these two numbers is the single most useful thing you can show a team. The heuristic rate is what they feel their discipline is; the strict rate is what their tooling can actually enforce. In one illustrative portfolio scan of 52 projects, the "anywhere" rate looked reassuring while the strict dedicated-field rate lagged far behind — and every downstream quality report was running on the strict number. (Figures illustrative.)
What good AC discipline unlocks
- Enforceable definition of done: a done-criteria rule can require the field before a story closes.
- Trustworthy reporting: coverage dashboards reflect reality instead of undercounting well-specified work.
- Better testing: criteria in a distinct field are far easier to turn into linked test cases — which feeds directly into test-cases-per-story quality signals.
- Fewer defects: work that starts with clear, addressable criteria tends to come back as a bug less often.
How to measure and fix it org-wide
You don't fix AC discipline story by story — you fix it as a portfolio behaviour. The sequence that works:
- Measure the strict rate per project. Compute the dedicated-field AC rate for every project so you can see which teams are genuinely disciplined and which only appear to be.
- Show teams the gap. Put the strict rate next to the "anywhere" rate. The gap is a far more persuasive prompt than any policy memo.
- Migrate existing criteria. Move AC out of the Description and into the field on active work, so current reporting stops undercounting.
- Put the field in the definition of done. Make a populated AcceptanceCriteria field a close condition so new work is captured correctly from the start.
Done consistently, the strict rate climbs, and — because so many other quality signals depend on it — the rest of the portfolio's quality picture improves with it.
See your real acceptance-criteria rate — free
HAPI (Helix ADO Portfolio Inspector) scans your Azure DevOps portfolio using work-item metadata only — code never leaves your ADO boundary — and reports the strict, dedicated-field AC rate per project alongside a red/amber/green verdict, concrete behaviour-change targets, a shareable executive report, and a per-project workbook.
Run a free scan →Frequently asked questions
Where should acceptance criteria go in Azure DevOps?
In the dedicated Acceptance Criteria field on the work item, not in the Description. The dedicated field is the only place tooling, reporting, and done-criteria enforcement can reliably read, so criteria written into the Description are effectively invisible to any automated check.
Why can't reporting read acceptance criteria in the Description?
Reporting can technically read the Description text, but it cannot reliably tell criteria apart from the rest of the narrative. The AcceptanceCriteria field is a distinct, machine-addressable field, so a tool can check it deterministically. Free-text in the Description is not something a tool can trust.
What is the difference between strict and heuristic AC measurement?
Strict measurement counts a story as having acceptance criteria only when the dedicated AcceptanceCriteria field is populated. Heuristic (or anywhere) measurement counts AC appearing anywhere, including the Description. The gap between the two numbers reveals how much of a team's AC is invisible to tooling.
How do you improve acceptance-criteria discipline org-wide?
Measure the strict dedicated-field rate per project, show teams the gap between what they believe and what tooling can see, migrate existing criteria out of the Description into the field, and add the field to your definition of done so new work is captured correctly.