Requirements Gathering and Business Analysis Questions

Checklist for clear acceptance criteria (AC) — adopt as a team rulebook:

1. Title & Context: one-line goal + related user story ID.
   Why: orients reviewers and links AC to expected behavior.

2. “Given/When/Then” format for each criterion (explicit preconditions, action, outcome).
   Why: forces concrete, testable steps and removes ambiguous verbs like “should”.

3. Acceptance conditions are measurable (pass/fail), with examples and data ranges.
   Why: removes interpretation — QA and PO can objectively validate.

4. Define UI/UX specifics or link mockups (states, error messages, edge cases).
   Why: prevents visual/interaction debates during review.

5. Performance & non-functional limits (latency, throughput, storage).
   Why: sets expectations beyond happy-path functionality.

6. Dependencies & setup steps (feature flags, required services, test accounts).
   Why: ensures implementers and testers can reproduce scenarios.

7. Out-of-scope list (what this story will not do).
   Why: prevents scope creep and late disagreement.

8. Owner sign-offs: PO, Tech lead, QA confirm AC are complete before dev starts.
   Why: creates shared responsibility and reduces mid-sprint changes.

9. Add at least one automated testable criterion (unit/integration/end-to-end).
   Why: Encourages automation and prevents regressions.

10. Review checklist in grooming with timeboxed read-through and “clarity vote” (ready/not ready).
    Why: Ensures the team actively verifies readability and agreement before sprint planning.

Adopt these as a template in the ticketing tool; enforce during grooming to reduce ambiguity and conflicts.