Acceptance criteria for user stories: definition, formats and role in delivery

As a product manager, you are asked a concept question: what are acceptance criteria, and what are they used for? Explain the term as you would to a new teammate, and walk through how a team relies on acceptance criteria from planning a piece of work to signing it off. ```hint Follow one story through the sprint Trace a single story from the moment the team first discusses it to the moment someone decides it is finished. At each step, ask what could go wrong if nobody had written down beforehand what that story must do. ``` ### Clarifying Questions - Should I answer in terms of agile user stories, or requirements documents more generally? - Would you like me to cover how the criteria are written, such as common formats, or only what they are and why teams use them? - Should I explain how acceptance criteria relate to the team's definition of done? ### What a Strong Answer Covers - A definition precise enough to separate acceptance criteria from team-wide quality rules and from loosely worded requirements. - How the criteria are used at each stage of a story's life, from refinement to sign-off, rather than a single use. - At least one common way of writing them, with a short example that includes an unhappy path. - Clear boundaries between acceptance criteria and the other artifacts a team uses to judge its work, with the reason each distinction matters. - Ownership and timing: who drafts and refines the criteria, when they should be settled, and what separates a weak set of criteria from a strong one. ### Follow-up Questions - Write acceptance criteria for a story that lets a cardholder freeze a lost card in a mobile app. - Who should write acceptance criteria, and at what point should they be final? - A story meets every acceptance criterion, yet users still find the feature confusing. What went wrong, and what would you change?