Acceptance criteria often begin as a short list inside a User Story, Product Backlog Item, Issue, Requirement, or custom work item. The list is easy to read during refinement. It becomes harder to trace after the wording changes, Test Cases appear, automation is added, and several executions compete to represent the release.

The solution is not to turn every sentence into another work item. A lightweight, stable identity is usually enough:

AC-01 — A retry with the same idempotency key returns the original successful result.
AC-02 — Reusing the key with different payment details is rejected.
AC-03 — The checkout page shows the existing payment result without resubmission.

AC-01 is not a native Azure DevOps object. It is a team convention that allows a criterion to survive editing and appear consistently in a Test Case, automated-test mapping, review note, or production Bug.

Azure Boards work item with stable AC-01 through AC-04 labels and native branch and commit links.

The work item, branch, and commit are native Azure objects. The AC labels are a lightweight convention inside the work-item text.

Start with observable behavior

A traceable criterion describes a result someone can observe and verify. It should make the important boundary explicit without prescribing every implementation detail.

Compare these two versions:

AC-01 — Handle duplicate payments correctly.
AC-01 — Given a completed payment, when the same idempotency key is retried with the
same payment details, then the original successful result is returned and no second
charge is created.

The first version names an intention. The second identifies the starting state, action, result, and safety condition. A reviewer can now design a manual Test Case, automated API test, or exploratory charter for the same behavior.

Good acceptance criteria normally answer:

  • what state or precondition matters
  • which action or event occurs
  • which externally visible result is expected
  • which important side effect must not occur
  • which boundary values or error cases need separate criteria

Do not force every criterion into Given/When/Then when a concise rule is clearer. The important properties are stable identity, observable behavior, and one reviewable idea.

Login acceptance criteria example

The user can log in is too broad to design or trace well. Separate the main behavior, invalid credentials, account state, and session handling while keeping one stable ID per behavior:

AC-01 — Given an active account, when the user submits the correct email and password,
the application creates an authenticated session and opens the requested protected page.

AC-02 — When the submitted credentials are invalid, the application does not create a
session and shows the same safe error message for an unknown email and a wrong password.

AC-03 — When a locked account submits otherwise correct credentials, the application does
not create a session and shows the approved account-recovery action.

AC-04 — After the configured inactivity period, the session expires and the next protected
request requires authentication again without losing unsaved data silently.

These are examples, not a universal authentication specification. Multi-factor authentication, rate limits, trusted devices, single sign-on, recovery, privacy, and accessibility need their own criteria when they belong to the product scope. The point is to make each accepted behavior observable and independently traceable.

Azure DevOps tracks the work item, not each rich-text criterion

Azure DevOps gives the work item a stable ID and revision history. The ordinary Acceptance Criteria or Description field is still rich text. Individual bullets do not receive native IDs, relations, owners, or lifecycle states. Microsoft also documents that the Analytics Service does not support reporting on plain-text and HTML fields in the work item field reference.

This boundary explains why splitting HTML bullets is not a defensible coverage model. A parser cannot reliably decide whether a rewritten bullet is the same criterion, a replacement, or two new behaviors.

Use stable labels when criterion-level traceability matters. Do not present them as an Azure feature or assume that Azure validates their uniqueness.

Keep the identifier stable when wording improves

Use a small lifecycle rule for every label:

  1. Keep the ID when wording becomes clearer but the behavior remains the same
  2. Create a new ID when the behavior or business outcome materially changes
  3. Retire an obsolete ID instead of renumbering the remaining list
  4. Record when one criterion splits into several or several criteria merge
  5. Review its test mappings whenever the meaning changes

Suppose AC-02 originally says that conflicting key reuse is rejected. A later review clarifies that the response must be HTTP 409 and contain the original transaction ID. If that is a clarification of the same product behavior, keep AC-02. If the response contract introduces a separately owned compatibility requirement, create another ID.

The exact split is a product decision. The traceability rule merely prevents silent denominator drift.

Give each criterion one primary behavior

Avoid a single criterion that joins unrelated responsibilities:

AC-04 — Support can find the payment, finance receives a report, the shopper gets an
email, and the dashboard updates within five minutes.

One test might cover search, another notification, and another reporting latency. A single pass/fail mapping would hide which behavior is missing.

Split the criterion when the parts can fail, ship, or be owned independently. Keep them together when they describe one atomic outcome whose parts have no useful independent meaning.

Connect the criterion to tests without duplicating the whole suite

Teams that use Azure Test Plans can add the stable key to the relevant Test Case title or another reviewed field:

[1842:AC-01] Return the original payment result
[1842:AC-02] Reject conflicting idempotency-key reuse

A requirement-based suite creates the native relation between the requirement work item and those Test Cases. Microsoft documents that relation in Create and manage test suites. The 1842:AC-02 fragment supplies the criterion-level identity that Azure does not create from rich text.

Requirement-based suite containing Test Cases labeled with stable acceptance-criteria identifiers.

The suite confirms the requirement–Test Case relation. The AC key explains which criterion the Test Case is intended to verify.

Automation-first teams do not need to recreate every automated test as a Test Case. They can maintain a reviewed mapping next to test code:

requirement: 1842
criteria:
  AC-01:
    automated:
      - checkout.api.returns-original-result
  AC-02:
    automated:
      - checkout.api.rejects-conflicting-retry

Azure DevOps does not interpret this file natively, and QaCockpit does not read it today. It is an example of a portable convention for teams that treat test code as the primary test definition.

Separate designed, automated, executed, and passed

A mapped Test Case does not prove that automation exists. An associated automated method does not prove that it ran for the selected release. A completed execution does not prove that every required criterion was included.

Keep four separate questions:

  • Does every eligible criterion have a designed test?
  • Which eligible criteria have mapped automation?
  • Did the required mapped tests run for the exact release context?
  • What were the conclusive outcomes?

This separation is developed further in acceptance-criteria coverage and applies at broader requirement and release scope too.

Review criteria at three moments

Before development

Confirm that every criterion has a stable ID, one observable behavior, and an agreed meaning. This is the cheapest moment to expose ambiguity.

Before test execution

Confirm that required tests or charters map to the accepted revision. Mark manual only, not mapped, or needs redesign instead of inventing an automated link.

Before the release decision

Confirm which exact tests executed for the selected build, artifact, environment, and attempt. Preserve not executed, inaccessible, and no evidence as different states.

What not to infer

Do not infer that:

  • bullet position is a stable criterion ID
  • a requirement-based suite covers every acceptance criterion
  • a similarly named automated test is a confirmed mapping
  • Automation Status = Automated means the method ran for this release
  • a green pipeline proves all eligible criteria were tested
  • a renamed criterion keeps the old mapping automatically

The correct answer can be unknown. That is more useful than a precise-looking number whose denominator cannot be reconstructed.

How QaCockpit uses this evidence

QaCockpit for Azure DevOps currently organizes accessible pipeline executions, published test results, missing evidence, logical test history, and selected campaign evidence. It does not currently parse acceptance-criteria text or read Test Plans mappings, so it does not claim criterion-level coverage.

The future product direction is to follow confirmed Azure relations and accepted team conventions while showing provenance and gaps. That direction is not a shipped feature. Stable IDs make future analysis more defensible, but teams can adopt them today without waiting for QaCockpit.

A practical review checklist

  1. Identify which work item types represent requirements in this project
  2. Give each durable criterion a stable label such as AC-01
  3. Describe one observable behavior per criterion
  4. Preserve the ID through wording clarifications
  5. Record split, merge, replacement, and retirement explicitly
  6. Map tests through Test Plans or a reviewed automation-first convention
  7. Keep manual-only behavior visible
  8. Review mappings after the criterion changes
  9. Select the exact execution before reporting coverage
  10. Publish a percentage only when every denominator row can be listed

Frequently asked questions

Are AC-01 labels built into Azure DevOps?

No. They are a recommended team convention inside the work-item text or another reviewed mapping. Azure DevOps tracks the parent work item and its revisions.

Should every acceptance criterion become a child work item?

Usually not. Child items can help when criteria require separate ownership, approval, or audit history. A lightweight stable label is enough for many teams.

Do I need Azure Test Plans?

No. Test Plans provides native requirement–Test Case relations. Automation-first teams can use stable logical test IDs and a version-controlled mapping instead.

Can an AI model map tests to acceptance criteria?

It can suggest candidates. The result should remain an inferred candidate until a person or deterministic accepted mapping confirms the relation.

Microsoft documentation and the synthetic Azure DevOps example were checked on October 1, 2026.