User Stories Are a Conversation Starter, Not a Requirements Document
The user story format — as a user, I want, so that — was not designed to specify behavior. It was designed to prompt a conversation about behavior. The distinction matters because teams that treat the card as the requirement skip the conversation, and the conversation is where the value lives.
Ron Jeffries described the three Cs: card, conversation, confirmation. The card is a placeholder for a conversation that has not yet happened. The conversation is where the team and the product owner develop shared understanding of what is actually needed. The confirmation — the acceptance criteria — is what that shared understanding looks like when written down in a testable form. The format is a starting point, not a destination.
Teams that write long, detailed user stories and consider the work done before refinement are writing requirements in user story clothing. The format does not make the practice agile. What makes it agile is the deferral of detail until it is needed, the collaborative development of that detail, and the use of working software to validate that the detail was right.
The acceptance criteria attached to a well-refinement story should be concrete and testable: given a specific condition, when an action occurs, then a specific outcome results. Criteria written at that level of specificity are both verifiable by QA and useful to whoever is implementing the story. Criteria written as vague statements of intent — the user should be able to manage their profile — are not acceptance criteria. They are the card, again, with different formatting.
The pathology to watch for is teams where product owners write exhaustive stories in isolation and hand them to development as finished specifications. This is waterfall with user story formatting. The stories may be detailed and carefully written, and the development team will still discover, during implementation, that significant things were not considered. The conversation would have surfaced those things. The document cannot.