Building Acceptance Criteria
Generate acceptance criteria for Jira tickets. Output in English, Jira Markdown, inside a code block.
Step 1 — Gather context
Before writing, verify you have the following. If any is missing, ask for it:
- What the feature or change does (business goal, not implementation detail)
- Who performs the action (user role or system actor)
- What the observable outcome is from a user/business perspective
- Scope restrictions if applicable (e.g., specific environments, feed-handlers, devices)
Ask only what is missing. Do not ask for things already provided.
Step 2 — Write the ACs
Apply these quality rules to every criterion:
- Binary: Each AC must have a clear pass or fail. Avoid vague outcomes like "works correctly" or "is shown properly".
- Testable: The outcome must be verifiable through a concrete observable action — not inferred from code behaviour.
- Implementation-independent: Describe *what* the system does, not *how* it does it internally. Avoid referencing internal flags, class names, or code constructs unless they are part of the user-visible contract.
- Business language: Write so that any stakeholder (product owner, QA, business analyst) can understand it without technical knowledge.
- Real scenario: Ground each AC in an authentic business flow (e.g., "a user completes a purchase"), not an abstract system state.
Output Format
Output the criteria in a single code block using this template:
h2. Acceptance Criteria
*AC.1* → Given [initial context / precondition], When [user or system action], Then [observable outcome].
*AC.2* → Given [initial context / precondition], When [user or system action], Then [observable outcome].Output Rules
- Each AC must be self-contained and testable.
- Use the
→separator between the AC identifier and the Gherkin sentence. - Keep each criterion to a single sentence. No bullet sub-lists inside an AC.
- If scope or feed-handlers apply, append them in parentheses at the end:
(DC, LF, BRU). - Number sequentially starting at AC.1.
- No filler text. No preamble outside the code block.
Example Output
h2. Acceptance Criteria
*AC.1* → Given a confirmed event total has been received for the current period, When the system processes the settlement, Then all affected markets are settled and their status is visible to the user as "Settled". (DC, LF, BRU feed-handlers.)
*AC.2* → Given an unconfirmed event total has been received, When the system processes it, Then no markets are settled and their status remains unchanged. (DC, LF, BRU feed-handlers.)