What user story details reveal the customer problem?

WHAT THIS TESTS: This question checks whether you understand that a user story is a placeholder for a conversation about a customer problem, not a technical specification or task list. Interviewers want to see that you prioritize the three Cs from Ron Jeffries: Card, Conversation, and Confirmation. They are listening for whether you insist on knowing who the user is, what action they need, and why it matters before you write any code.

A GOOD ANSWER COVERS: First, the identity of the user or stakeholder, expressed as a specific role or persona rather than a system component. Second, the action the user wants to perform, kept at the problem level rather than the implementation level. Third, the value or justification, usually captured in the so that clause, which explains the business or customer outcome. Fourth, confirmation criteria that describe what should be true when the problem is solved, not how the system should be built. Fifth, the expectation of ongoing conversation with stakeholders, since most of the understanding comes from dialogue, not the written text.

COMMON WRONG ANSWERS: Treating the story as a design document by asking for API contracts, database schemas, or UI mockups in the initial ticket. Listing only technical acceptance criteria such as deploy the service or add a column to the table without connecting them to observable user outcomes. Demanding rigid templates or JIRA fields as if structure matters more than content. Forgetting the so that clause entirely and focusing only on what to build rather than why.

LIKELY FOLLOW-UPS: How would you handle a story where the stakeholder cannot articulate the value? What do you do when a story is too large to fit in a sprint but the team wants all the details up front? How do you prevent acceptance criteria from turning into a technical task list? Can you give an example of a story that was well written versus one that was just a requirement?

ONE CONCRETE EXAMPLE: A weak story says As a developer, I want a REST endpoint, so that the frontend can call it. A strong story says As a returning shopper, I want to see my saved payment method, so that I can check out in under thirty seconds without re-entering my card. The confirmation criteria for the strong version would state that the saved method appears on the checkout screen and that the average checkout time for returning users drops, whereas the weak version offers no customer problem to validate.

Source: Scrum Alliance - The Anatomy of a User Story