Acceptance Criteria Definition Of Done

Overview

Acceptance criteria are the contractual boundary between what a development team builds and what the business considers "done." When they are written well, acceptance criteria eliminate ambiguity, prevent scope creep, accelerate testing, and create a shared language between business analysts, developers, and QA engineers. When they are written poorly — vague, incomplete, or untestable — they become a source of constant friction: developers building the wrong thing, testers unable to verify without asking questions, and business stakeholders discovering gaps only during UAT or, worse, in production.

The Definition of Done is the team-level complement to acceptance criteria. While acceptance criteria define what "done" means for a specific story, the Definition of Done defines the universal quality bar that every story must meet regardless of its specific acceptance criteria — the technical, documentation, testing, and review standards that the team applies consistently to all work. Together, acceptance criteria and the Definition of Done form the quality governance framework for agile delivery.

AI dramatically accelerates both activities. For acceptance criteria, AI can generate comprehensive coverage across functional behavior, data validation, error handling, and security dimensions in minutes — producing a first draft that would take an experienced BA an hour or more to write manually. More importantly, AI can audit existing acceptance criteria for coverage gaps, missing edge cases, and untestable statements in a way that is both systematic and faster than manual review. For the Definition of Done, AI can generate role-specific, story-type-specific, and project-context-specific DoD checklists that reflect the team's actual quality standards rather than generic agile templates.

This topic covers the complete AI-assisted workflow for acceptance criteria development and Definition of Done creation: from generating precise Gherkin-format criteria from business rules, through coverage auditing and gap filling, to DoD customization and pre-development validation. The goal is not to remove human judgment from these activities but to ensure that human judgment is applied to the right questions — the ones that require domain knowledge and product experience — rather than to the mechanical work of coverage enumeration.

Generating Precise, Testable Acceptance Criteria from Business Rules

Business rules are the raw material of acceptance criteria. A business rule is a statement of how the business operates: "Purchases above $10,000 require CFO approval," "Invoices must be paid within 30 days of goods receipt," "A supplier is considered inactive if no PO has been issued in the past 12 months." These rules are embedded in policy documents, system logic, SOPs, stakeholder interview notes, and the institutional knowledge of experienced staff. The BA's job is to extract these rules and express them as testable acceptance criteria.

The Gherkin format — Given/When/Then — is the gold standard for testable acceptance criteria. Its structure directly maps to test case design: Given describes the precondition state (what must be true before the scenario begins), When describes the trigger event (the action the user takes or the system event that occurs), and Then describes the expected outcome (what the system must do or what state it must reach). This structure is precise enough to be implemented directly as automated test code (using tools like Cucumber or SpecFlow) and clear enough for manual testers to verify without additional documentation.

Coverage dimensions define the completeness of acceptance criteria for any meaningful feature. Functional behavior criteria cover the primary user flows — what happens when everything works correctly. Data validation criteria cover the rules that govern what inputs are acceptable — format, range, completeness, and cross-field dependencies. Error handling criteria cover what happens when inputs are invalid, required data is missing, or a dependent system is unavailable. Security and permission criteria cover who is allowed to perform the action, what happens when an unauthorized user attempts it, and what audit trail is created. Comprehensive acceptance criteria address all four dimensions, not just the functional happy path.

AI generates high-quality Gherkin criteria when given a well-specified business rule and an explicit instruction to cover all four dimensions. The most effective prompting technique is to provide the business rule in plain English, then ask AI to: (1) convert it to a primary acceptance criterion in Gherkin format, (2) generate at least two data validation criteria, (3) generate at least two error handling criteria, and (4) generate at least one security/permission criterion. This structured instruction reliably produces comprehensive first-draft criteria.

Hands-On Steps

1. Extract the business rules relevant to the story from your requirements documentation. For each story, identify: the primary business rule (what must happen in the normal case), any data validation rules (what inputs are valid/invalid), the downstream systems or data stores affected, and the permission model (who can perform this action).
2. Write each business rule as a plain-English statement before converting it to Gherkin. A precise natural language statement produces a precise Gherkin criterion.
3. Run a Gherkin conversion prompt for each business rule, specifying all four coverage dimensions.
4. Review the generated criteria for testability: can a QA engineer run this test without asking any questions? If not, identify what is missing and add it.
5. Check for undefined terms in the criteria: any term that requires interpretation (e.g., "valid," "recent," "significant") must be replaced with a precise definition.
6. Run a coverage completeness check prompt: "Review these acceptance criteria and identify any coverage dimension that is missing or underdeveloped."
7. For any missing coverage, generate the additional criteria using targeted prompts by dimension (data validation prompts, error handling prompts, security prompts).
8. Add the acceptance criteria to the story in your backlog tool. Format them consistently — each criterion should have a unique ID (AC-01, AC-02, etc.) so they can be referenced in test cases and defect reports.

Prompt Examples

Prompt:

You are a senior business analyst writing acceptance criteria for an agile development team.

Here is the user story and its business rules:

Story: "As a procurement manager reviewing a purchase request, I want the system to automatically check available budget for the cost center before I approve, so that I can prevent budget overruns before they occur rather than discovering them in the monthly budget review."

Business rules:
- Rule 1: Before displaying the approval screen for a PO, the system must retrieve the current available budget for the cost center associated with the PO's cost code.
- Rule 2: Available budget = Approved annual budget - Year-to-date actual spend - Total of all approved-but-not-yet-received POs (committed budget).
- Rule 3: If the PO amount would reduce available budget to below zero, the system must display a warning and require the approver to explicitly acknowledge the overrun before approving.
- Rule 4: If available budget is negative before the PO is even considered (i.e., already overspent), the system must display an error and prevent approval until the budget is corrected or a budget exception is authorized.
- Rule 5: Budget check must use real-time data — it cannot use cached or batch-updated budget figures.

Generate acceptance criteria in Given/When/Then format. Cover all four dimensions:
1. Functional behavior (happy path: PO within budget)
2. Data validation (boundary conditions: PO that exactly uses remaining budget, PO that would cause minor overrun, PO that would cause major overrun)
3. Error handling (budget already negative, SAP budget service unavailable, cost code not found in budget system)
4. Security/permission (read-only user, approver role, budget manager override role)

Use this format for each criterion:
AC-[number]: [Brief title]
Given [precondition]
When [action or trigger]
Then [expected outcome]
And [additional expected outcome if needed]

Expected output: A comprehensive set of 10-15 acceptance criteria covering: AC-01 (PO well within budget — straightforward approval), AC-02 (PO exactly exhausts remaining budget — boundary condition, approval allowed with notification), AC-03 (PO would create minor overrun — warning displayed, acknowledgment required before approval), AC-04 (PO would create major overrun — same warning but with escalation requirement), AC-05 (budget already negative — error state, approval blocked), AC-06 (SAP budget service unavailable — what does the approver see? Is approval blocked or degraded-mode allowed?), AC-07 (cost code not recognized in budget system — error state), AC-08 (read-only user attempts to access approval screen — access denied), AC-09 (audit trail — every approval action, including acknowledged overruns, must be logged with approver identity and timestamp).

Prompt:

You are a senior business analyst converting business rules into testable acceptance criteria.

Here are the business rules for a supplier onboarding feature in the procurement platform:

"New suppliers can only be added to the approved supplier list by a Procurement Manager or above. A supplier record requires: legal company name, ABN/ACN (Australian Business Number, 11-digit numeric), primary contact name and email, payment terms (select from: 14 days, 30 days, 45 days, 60 days), and at least one approved purchasing category. The ABN must be verified against the Australian Business Register before the supplier can be activated. Duplicate suppliers (same ABN already in the system) must be detected and blocked. A new supplier starts in 'Pending Verification' status and can only be moved to 'Active' after ABN verification is successful. An inactive supplier (last PO more than 12 months ago) is automatically moved to 'Inactive' status and cannot receive new POs without being reactivated by a Procurement Manager."

Convert these business rules into acceptance criteria. For the ABN validation rules specifically, generate boundary condition criteria:
- Valid ABN format (exactly 11 digits, numeric only)
- Invalid formats: 10 digits, 12 digits, contains letters, contains spaces, empty
- Valid format but not found in the ABR (valid format, invalid registration)
- Valid format, found in ABR, but ABN is cancelled (deregistered business)
- Duplicate ABN (same ABN already active in the system)
- Duplicate ABN (same ABN but existing record is Inactive)

Use Given/When/Then format with unique AC numbers. Group criteria by business rule area.

Expected output: A structured set of 20+ acceptance criteria grouped by area: Supplier Creation Permission (who can create), Mandatory Field Validation (what fields are required with what format), ABN Format Validation (the 6 boundary condition criteria listed), ABN Registry Verification (live verification call outcomes), Duplicate Detection (active and inactive duplicate scenarios), Status Lifecycle (Pending → Active → Inactive transitions), and Reactivation (who can reactivate and under what conditions). This level of coverage is what prevents a "simple" supplier onboarding feature from generating 15 defects in QA.

Learning Tip: When you ask AI to generate acceptance criteria, always specify the coverage dimensions explicitly in the prompt. Without explicit coverage instructions, AI defaults to writing functional happy-path criteria and produces 3-4 criteria where 12-15 are needed. The prompt instructions "cover data validation, error handling, and security" are not overhead — they are the difference between a story that passes QA in one cycle and one that generates a defect parade.

Using AI to Ensure Coverage of Happy Paths, Error Paths, and Edge Cases

Even well-written acceptance criteria commonly suffer from coverage gaps — not because the BA wrote poor criteria, but because comprehensive path coverage is cognitively demanding. Writing acceptance criteria for the happy path is intuitive; writing them for the error paths requires systematically imagining everything that can go wrong; writing them for edge cases requires thinking about the extreme boundaries of the input space. This is mentally taxing and prone to the gaps that appear obvious in hindsight.

AI coverage auditing addresses this problem directly. Given a set of acceptance criteria, AI can systematically evaluate coverage across a defined set of path categories and identify precisely which categories are missing or underspecified. The audit is not a judgment — it is a structured inventory of what is and is not present.

The most common coverage gaps in practice fall into five categories. Zero state gaps: what does the user see or experience when there is no data to display or act on (empty search results, empty queue, no items in the list)? Permission boundary gaps: what happens when a user attempts an action they do not have permission to perform — do they see an error, are they redirected, are they invisible to the feature entirely? Integration failure gaps: what happens to the user and the data when a dependent service is unavailable — does the UI show a generic error, a specific message, a degraded-mode option? Data freshness gaps: for features that display or process data from other systems, what is the acceptable staleness of that data and what happens when the data source is unavailable? Concurrent action gaps: what happens if two users attempt to perform conflicting actions simultaneously — approve the same PO, submit the same order, modify the same record?

A coverage audit prompt should be structured to check for each of these categories specifically, plus any domain-specific coverage dimensions relevant to the feature being specified. The output is a list of missing criteria with enough specificity that the BA can generate the additional criteria immediately, without further elicitation.

Hands-On Steps

1. Take a complete set of acceptance criteria for a story — after your initial generation pass.
2. Run a path coverage audit prompt that checks for: happy path, alternative valid paths, validation failures, system/integration failures, boundary conditions, zero states, permission edges, and concurrent action scenarios.
3. Review the coverage audit output. For each missing category, decide: (a) is this coverage needed for this story (generate additional criteria), (b) is this out of scope for this story but relevant for a related hardening story (log it), or (c) is this genuinely out of scope for this feature (dismiss it with a note).
4. For each category where coverage is missing and needed, run a targeted criteria generation prompt: "Generate acceptance criteria for the [error handling / zero state / permission boundary] scenarios for this story."
5. Review the newly generated criteria against the existing ones: are there any new criteria that contradict existing ones? Any that duplicate them?
6. Run a final completeness check: "Given a QA engineer who has never attended any product meetings, are these acceptance criteria complete enough for them to design and execute a comprehensive test suite without asking questions?"
7. Address any remaining gaps flagged by the final completeness check before moving the story to "Ready" status.

Prompt Examples

Prompt:

You are a senior QA engineer and business analyst performing a coverage audit on acceptance criteria.

Here is the user story and its current acceptance criteria:

Story: "As a procurement manager, I want to approve or reject purchase requests from my approval queue, so that approved requests can proceed to PO creation and rejected requests are returned to the requester with a reason."

Current Acceptance Criteria:
AC-01: Given I am logged in as a Procurement Manager, When I open my approval queue, Then I see all purchase requests awaiting my approval, sorted by submission date ascending.
AC-02: Given a purchase request is in my approval queue, When I click 'Approve', Then the request status changes to 'Approved', the requester receives an email notification, and the request is removed from my queue.
AC-03: Given a purchase request is in my approval queue, When I click 'Reject' and enter a rejection reason, Then the request status changes to 'Rejected', the requester receives an email notification with the rejection reason, and the request is removed from my queue.
AC-04: Given a purchase request is in my approval queue, When I click 'Reject' without entering a rejection reason, Then the system displays an error message and does not submit the rejection.

Audit these acceptance criteria for coverage gaps. For each of the following path categories, indicate:
- Coverage status: Covered / Partially Covered / Not Covered
- If not covered or partially covered: write the missing acceptance criterion in Given/When/Then format

Path categories to audit:
1. Alternative valid approval paths (bulk approval, delegation to another approver)
2. Data validation (what happens if a PO amount has changed since it was submitted — does the approver see the current or submitted amount?)
3. Integration failure (what if the email notification service is unavailable when approval is submitted?)
4. Zero state (what does the approver see when their queue is empty?)
5. Permission boundary (what happens if a non-Procurement-Manager role accesses the approval queue URL directly?)
6. Concurrent action (what if two approvers try to approve the same PO simultaneously — e.g., a delegated and primary approver?)
7. Audit trail (is there a requirement for approval actions to be logged for compliance?)
8. SLA and time-based behavior (is there any behavior triggered if a PO sits in the queue unapproved for more than X hours?)

Expected output: A coverage audit showing that categories 1, 3, 4, 5, 6, 7, and 8 are not covered by the current four criteria. Each missing category should include a generated acceptance criterion — for example, AC-05 (empty queue): "Given I am a Procurement Manager with no pending requests, When I open my approval queue, Then I see a message 'Your approval queue is empty. No requests are currently awaiting your approval.'" and AC-08 (concurrent approval): "Given a purchase request has been approved by Approver A, When Approver B (who had the same request in their delegated queue) attempts to approve the same request, Then the system displays a message 'This request has already been approved by [Approver A name] at [timestamp]' and no duplicate approval action is recorded."

Prompt:

You are a senior business analyst generating missing acceptance criteria for identified coverage gaps.

Here is the story context: A goods receipt feature where warehouse staff record the receipt of goods against an existing purchase order. The receipt records: PO number reference, items received (line by line), quantities received, condition (acceptable/damaged), and the warehouse team member's ID.

The following coverage gaps have been identified in the current acceptance criteria:

Gap 1 — Partial receipt: Current AC only covers full receipt (all items and quantities received). Need criteria for partial receipt (some items not yet delivered).
Gap 2 — Over-receipt: No criteria for receiving more items than the PO quantity (a common error).
Gap 3 — Damaged goods: No criteria for the workflow when items are marked as damaged.
Gap 4 — PO already fully received: No criteria for attempting to create a receipt against a PO that has already been 100% received.
Gap 5 — PO cancelled after shipment: No criteria for receiving goods against a PO that has been cancelled in the system.

For each gap, write 1-3 acceptance criteria in Given/When/Then format that completely address the gap. Include any business rule assumptions you are making, flagged for BA validation.

Expected output: A set of 8-12 additional acceptance criteria addressing the five gaps. For Gap 2 (over-receipt), the criterion should make an explicit business rule assumption: "Assumption: The business rule for over-receipt must be confirmed — this criterion assumes that over-receipt is blocked by the system (as opposed to allowed with a warning), and that the warehouse team must contact procurement to authorize a PO quantity amendment before recording quantities above the PO amount." This flags the assumption clearly for the BA to validate with stakeholders rather than embedding an unverified business rule assumption silently.

Learning Tip: Run the coverage audit as a separate conversation turn, after the initial criteria generation. If you ask AI to both generate criteria and audit them in the same prompt, it will focus on generating and do a shallow audit. A fresh audit prompt — where AI is reading criteria it did not generate — produces a more honest and thorough coverage assessment. Treat generation and auditing as two separate cognitive tasks, just as you would in a peer review process.

Generating Definition of Done Checklists Tailored to Team and Project Context

The Definition of Done is often treated as a one-time setup activity — defined at the start of a project, posted on the team wiki, and then rarely reviewed. This approach produces a DoD that gradually diverges from the team's actual working standards as the project evolves, the technology changes, and the team learns. A DoD that is not actively maintained becomes irrelevant, and an irrelevant DoD is worse than none — it provides false assurance that quality standards are being applied when they are not.

AI enables a more dynamic approach to DoD management. Rather than treating the DoD as a static document, teams can use AI to generate and refine DoD checklists that are tailored to specific story types, project phases, and team contexts. A DoD for a feature story in a consumer-facing web application has different requirements than a DoD for a data migration story or a security hardening spike. Generating these variants explicitly and maintaining them in the team's working agreements prevents the gap between the stated DoD and the actual work being done.

The dimensions of a comprehensive DoD fall into five categories: technical quality (code quality standards, test coverage thresholds, static analysis, security scanning), testing (unit tests written and passing, integration tests, end-to-end tests, performance tests for relevant stories), documentation (code comments, API documentation, user documentation updated, runbook or deployment notes), review (code reviewed by at least one peer, design reviewed by architecture if required, accessibility review for UI stories), and deployment (deployable to staging environment, smoke tests passing, feature flag configured if applicable, monitoring and alerting configured). Not all dimensions apply to all story types — and AI can identify which dimensions are relevant for each type.

Story types that benefit from differentiated DoDs include: feature stories (full DoD with all five dimensions), bug fixes (emphasis on regression test coverage — a bug that is fixed without a regression test is a bug waiting to recur), refactoring stories (emphasis on behavioral equivalence verification — tests that prove the refactored code does the same thing as the original), spike stories (emphasis on documented findings and decision recommendations rather than production-ready code), and infrastructure or DevOps stories (emphasis on runbook documentation, disaster recovery verification, and security scan completion).

Hands-On Steps

1. Document the team's current working context: technology stack (language, framework, testing tools), deployment environment (cloud provider, CI/CD pipeline), team size and composition, any regulatory or compliance requirements, and any known non-negotiable quality standards.
2. Run a baseline DoD generation prompt to produce the default DoD for feature stories in your team's context.
3. Review the generated DoD with the full team in a retrospective or team agreement session. Add items the team knows are important, remove items that are not applicable, and establish the non-negotiable vs. contextual items.
4. Run story-type-specific DoD generation prompts for each story type your team regularly works with (bug, feature, refactor, spike, infrastructure).
5. For each story-type-specific DoD, review the delta from the baseline: what is added, what is removed, and why.
6. Publish the DoD variants in your team's documentation system and link them from your sprint board template.
7. Review the DoD quarterly or after any significant change in: the technology stack, the deployment environment, the team composition, or a post-incident review that reveals a DoD gap.
8. Use AI to update the DoD when changes are needed: "Here is our current DoD for feature stories. We have just adopted Playwright for end-to-end testing. Update the DoD to reflect this change and add any related checklist items we should consider."

Prompt Examples

Prompt:

You are a senior engineering lead and agile coach helping a product team define their Definition of Done.

Team context:
- Product type: B2B SaaS web application (procurement platform)
- Frontend: React with TypeScript
- Backend: Node.js REST API, PostgreSQL database
- Infrastructure: AWS (ECS containers, RDS, S3)
- CI/CD: GitHub Actions pipeline with automated testing
- Testing tools: Jest (unit), Supertest (API integration), Playwright (end-to-end)
- Code review: Pull requests with at least 1 approver, branch protection enforced
- Monitoring: Datadog for application monitoring and logging
- Compliance: Financial data requires audit logging; GDPR compliance required for EU users
- Team size: 8 engineers, 2 BAs, 1 QA specialist
- Sprint length: 2 weeks

Generate a Definition of Done checklist for Feature Stories. Organize the checklist into the following dimensions:
1. Technical Quality
2. Testing
3. Documentation
4. Review and Approval
5. Deployment and Observability

For each checklist item:
- Write the item as a verifiable yes/no statement (not a vague aspiration)
- Indicate whether it is Mandatory (must be checked for every story) or Conditional (applies only when certain conditions are met — specify the condition)
- Add a brief note explaining why this item is important for this team's context

Target: 20-30 checklist items total.

Expected output: A context-specific DoD with 20-30 items including: Technical Quality items like "Unit test coverage for new code is ≥80% (Jest coverage report shows ≥80%)" and "No critical or high severity issues from static analysis (ESLint + SonarQube) — Mandatory"; Testing items like "Playwright end-to-end test written for the primary user flow — Mandatory for new features, Conditional on existing E2E coverage for minor UI changes"; Compliance items like "Audit log entries are created for all financial data writes (INSERT/UPDATE/DELETE on PO, approval, and payment tables) — Mandatory (GDPR/Financial compliance)"; Observability items like "Datadog dashboard updated or created for any new service or significant new feature — Conditional: required for features with performance SLAs."

Prompt:

You are a senior agile coach helping a team differentiate their Definition of Done by story type.

Here is our baseline Definition of Done for Feature Stories:
[Paste the generated feature DoD above]

We regularly work with these additional story types:
1. Bug Fix stories — fixing defects found in production or QA
2. Technical Refactoring stories — improving code quality without changing behavior
3. Spike stories — time-boxed investigation and research tasks
4. Data Migration stories — moving or transforming data between systems or schemas

For each story type, generate a modified Definition of Done that:
- Keeps all baseline items that still apply
- Removes items that are not applicable (with a brief explanation of why)
- Adds story-type-specific items that are important for this type but not in the baseline
- Highlights the 3 most important additions unique to this story type

Format each as a complete standalone checklist, not just the delta — the team should be able to use it without referring back to the baseline.

Expected output: Four complete DoD checklists. The Bug Fix DoD should add: "A regression test exists that would have detected this bug before it reached production — the test was either absent or insufficient before the fix," and "Root cause has been documented on the bug ticket with a one-sentence explanation of why the defect was not caught before production." The Spike DoD should replace most implementation items with: "A written output document exists that answers the spike's investigation question," "At least 2 architectural or implementation options are described with trade-offs," "A clear recommendation is made and its rationale is documented," and "Any follow-up stories identified during the spike are created in the backlog." The Data Migration DoD should add: "Pre-migration data count verified and documented," "Post-migration reconciliation query confirms row counts match," "Rollback procedure exists and has been tested," and "Data migration has been run in staging with production-equivalent data volume before production execution."

Learning Tip: Review your Definition of Done with the team immediately after every sprint where a defect escaped into QA, UAT, or production. Ask: "Is there a DoD item that, if it had been applied to this story, would have caught this defect?" If yes, add that item to the DoD immediately. The DoD should evolve based on the team's real-world failure modes — not based on what an agile framework says it should contain.

Validating Acceptance Criteria Completeness Before Development Starts

The most expensive point to discover a gap in acceptance criteria is during development — when a developer has to stop, raise a question, wait for an answer, and then potentially rework code they have already written. The second most expensive point is during QA — when a tester finds behavior that the acceptance criteria did not specify and the story must be sent back to the BA. Pre-development validation of acceptance criteria is an investment that pays back in multiples through reduced rework and smoother sprint delivery.

AI-assisted pre-development validation addresses the challenge that most acceptance criteria reviews are cursory. In a busy sprint refinement session, the team is running through 10-15 stories in 90 minutes — there is rarely time for the deep, systematic review that acceptance criteria deserve. AI can perform this systematic review in seconds, applying a consistent checklist to every story regardless of time pressure.

The completeness test for acceptance criteria is a single, demanding standard: after reading these acceptance criteria, could a developer build exactly one correct implementation, and could a tester verify that implementation without asking a single question? Any criterion that fails either test is incomplete. AI can simulate both of these perspectives — the developer reading for implementation clarity and the tester reading for verification completeness — and flag any criteria that fall short.

A pre-development checklist goes beyond acceptance criteria to validate the full readiness of a story: acceptance criteria complete and testable, test cases defined (or a plan for when they will be defined), all dependencies resolved (no "pending" items that the developer will need to wait for), and no open questions on the story that require business or technical input before coding can begin. AI can evaluate all four dimensions of story readiness in a single validation pass.

Hands-On Steps

1. For every story moving from "Refined" to "Ready" status, run an AI completeness validation prompt before the sprint planning ceremony.
2. Use two separate validation perspectives in the prompt: developer clarity (can a developer implement this without asking questions?) and tester completeness (can a tester verify this without asking questions?).
3. Review the validation output. For each flagged issue, determine if it can be resolved immediately (add the missing detail to the criteria) or requires stakeholder input (mark it as a blocker for "Ready" status).
4. For any story with unresolved open questions, do not move it to "Ready" status. Either resolve the questions before sprint planning or leave the story in "Refined" for a future sprint.
5. Run a dependency check prompt: "Are there any implicit dependencies in these acceptance criteria that are not explicitly resolved? Are there any system integrations, data sets, or other stories that must be completed first?"
6. For acceptance criteria that reference technical implementation details (database tables, API endpoints, specific system behaviors), confirm those details are accurate with the relevant developer or architect before the sprint starts.
7. Establish a team agreement: stories that fail the pre-development validation check do not enter the sprint. This agreement creates the right incentive for BAs to produce sprint-ready criteria before planning, rather than completing them during the sprint.

Prompt Examples

Prompt:

You are a senior business analyst and QA lead performing a pre-development validation of acceptance criteria.

Here is a user story and its acceptance criteria scheduled for the next sprint:

Story: "As a procurement manager, I want to export my approval queue to a CSV file so that I can share pending approvals with my team in our weekly review meeting."

Acceptance Criteria:
AC-01: Given I am on the approval queue page, When I click 'Export to CSV', Then the system downloads a CSV file containing all current items in my approval queue.
AC-02: Given the CSV export, When I open it, Then each row contains: Request ID, Requester Name, Item Description, Requested Amount, Cost Center, Submission Date, and Days Waiting.
AC-03: Given I click 'Export to CSV' when my approval queue is empty, When the export runs, Then the CSV file is downloaded with a header row but no data rows.
AC-04: Given I click 'Export to CSV' when my approval queue has more than 1,000 rows, When the export runs, Then all rows are included in the export (no truncation).

Evaluate these acceptance criteria from two perspectives:

Perspective 1 — Developer Implementation Clarity:
For each acceptance criterion, identify any aspect that a developer would need to ask a question to implement correctly. Consider:
- Undefined terms or formats (e.g., "current items" — does this include delegated items? Does it include items on hold?)
- Unspecified behavior (e.g., file naming convention for the downloaded CSV)
- Missing technical constraints (e.g., browser download behavior, maximum file size limits)
- Unspecified data formatting (e.g., date format in the CSV, currency format for amounts, number format for decimal quantities)

Perspective 2 — QA Verification Completeness:
For each acceptance criterion, identify any aspect that a QA engineer would need to ask a question to verify. Consider:
- Untestable assertions (e.g., "appropriate file" — what makes a file appropriate?)
- Missing negative test scenarios
- Missing performance or reliability criteria (e.g., how long should the export take for 1,000 rows?)
- Missing security criteria (e.g., can a user export another manager's queue by manipulating the request?)

For each issue identified, provide the specific additional acceptance criterion or clarification needed.

Expected output: A detailed validation report identifying 8-12 specific gaps across both perspectives. Developer gaps should include: file naming convention not specified (e.g., "approval_queue_export_[date].csv" vs. browser-default), date format not specified (ISO 8601 vs. locale-specific), whether "amount" is the requested amount or the approved amount, whether delegated items appear in the exporting manager's queue or the original approver's queue. QA gaps should include: export security (can the export endpoint be called with a different user's queue ID?), maximum export time SLA (no performance criterion for 1,000-row export), and behavior when the export process fails mid-generation (partial file vs. error message).

Prompt:

You are a senior business analyst running a pre-development readiness check on a user story.

Before this story can be pulled into the sprint, I need to verify it passes all readiness gates. Evaluate the following story against the complete pre-development readiness checklist:

Story: "As a supplier, I want to acknowledge a purchase order through the supplier portal so that the procurement team knows I have received and accepted the PO."

Acceptance Criteria: [Paste ACs here]

Evaluate against these readiness gates:

Gate 1 — Acceptance Criteria Completeness
- [ ] All acceptance criteria are in Given/When/Then format
- [ ] Happy path is covered
- [ ] Validation error paths are covered
- [ ] System failure paths are covered
- [ ] Zero state is covered
- [ ] Permission boundaries are covered
- [ ] Every term in every criterion is precisely defined

Gate 2 — Implementation Clarity
- [ ] A developer can determine exactly what to build from these criteria alone
- [ ] No criterion requires design decisions that haven't been made
- [ ] All referenced data entities (PO, acknowledgment, etc.) are defined in the data model

Gate 3 — Dependency Resolution
- [ ] All predecessor stories that this story depends on are marked Complete or are in the same sprint
- [ ] All external dependencies (API availability, data setup, environment configuration) are resolved
- [ ] Any referenced test data or test environment requirements are documented

Gate 4 — Open Questions
- [ ] No open questions remain on the story that require stakeholder input before coding
- [ ] Any assumptions embedded in the criteria have been validated with the relevant stakeholder

For each gate item that fails, provide a specific description of what is missing and what needs to be done to resolve it.

Expected output: A structured readiness report with pass/fail for each gate item and specific resolution actions for failures. Common failures for a supplier portal story include: Gate 1 missing the integration failure path (what does the supplier see if the portal cannot connect to the procurement platform?), Gate 2 noting that the acknowledgment data model is not yet defined (what fields does an acknowledgment contain? Is there a comment field?), and Gate 3 flagging that the supplier authentication story must be complete before this story can be implemented (a supplier cannot acknowledge a PO if they cannot log into the portal).

Learning Tip: Build the pre-development validation into your team's Definition of Ready as a formal gate — not as an advisory step. A story does not enter the sprint unless it passes the validation. This policy sounds strict but it produces a dramatic improvement in sprint predictability: teams that adopt this practice consistently report fewer mid-sprint blockers, fewer defect escapes from QA, and fewer "completed but failed UAT" stories. The upfront investment in completeness pays back in every sprint.

Key Takeaways

• Always specify all four coverage dimensions when prompting for acceptance criteria: functional behavior, data validation, error handling, and security/permission. Without explicit instructions, AI generates functional happy-path criteria only.
• Gherkin format (Given/When/Then) is the gold standard for testable acceptance criteria. Every term in every criterion must be precisely defined — "valid," "recent," and "appropriate" are untestable unless defined.
• Run the coverage audit as a separate prompt from initial generation. Generating and auditing in the same prompt produces shallow auditing — treat them as two distinct cognitive steps.
• The five most common coverage gaps are: zero states, permission boundaries, integration failure scenarios, data freshness requirements, and concurrent action scenarios. Check explicitly for each.
• Generate story-type-specific Definitions of Done for features, bug fixes, refactors, spikes, and data migrations. The baseline DoD does not fit all story types, and forcing it to fit creates either false assurance or unnecessary friction.
• Review the DoD after every defect escape. The best DoD updates come from real failure modes, not from agile framework recommendations.
• Pre-development validation should be a formal readiness gate, not an advisory step. Stories that fail the validation check do not enter the sprint — this investment pays back in sprint predictability and defect reduction.
• The completeness standard for acceptance criteria is demanding: a developer can build exactly one correct implementation, and a QA engineer can verify it without asking a single question. Apply this standard rigorously before marking any story as Ready.