product-user-story-acceptance-criterialisted

# User Stories and Acceptance Criteria ## Purpose Stories get rejected in review for two reasons: they are horizontal slices that deliver nothing observable on their own, and their acceptance criteria describe intent rather than verifiable behaviour. This skill enforces vertical slicing and a criteria format that a tester can execute — including the negative paths, which is where most defects and most mid-sprint clarification requests come from. ## Prerequisites - **Inputs:** an agreed requirement source — a PRD, epic, or written request — identifying the user, the problem, and the priority. Stories written from a verbal instruction acquire the ambiguity of the instruction. - **Access:** whoever can answer behaviour questions (the product owner), and the existing system behaviour where the story modifies it. - **Also required:** the definition of ready and definition of done your team uses. If the team has none, the checklists below are the minimum. If the requirement's expected behaviour on failure or edge input is unknown, ask before writing criteria. Inventing a plausible error behaviour puts a decision into the backlog that nobody made. ## Data classification **Internal.** Do not put real customer data, account numbers, credentials, or personal identifiers into stories, criteria, or test data examples. Use obviously synthetic values. If someone supplies a real record to illustrate a case, flag it and replace it with a synthetic equivalent before the story i