What are the components of a well-written user story?

WHAT THIS TESTS: This question assesses your understanding of a user story's function as a communication tool, not just a format to memorize. It tests if you can connect product requirements to engineering execution by ensuring work is valuable, clearly scoped, and verifiably complete. For a senior role, the interviewer wants to see that you think about the 'why' behind the process—how stories reduce ambiguity and align the team on delivering user value.

A GOOD ANSWER COVERS: First, the standard format: 'As a [persona], I want to [action/goal], so that [value/outcome]'. Explain that the persona builds empathy, the action defines the work, and the value provides the business context needed for prioritization and trade-offs. Second, the '3 Cs' framework: the Card is the written story, the Conversation is the essential dialogue between product, engineering, and design to clarify details, and the Confirmation is the set of acceptance criteria that prove the story is done. Third, the INVEST criteria for a good story: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Finally, define Acceptance Criteria (ACs) as binary, testable conditions of satisfaction, often in a 'Given-When-Then' format.

COMMON WRONG ANSWERS: Simply reciting the 'As a...' template without explaining its purpose is a junior-level answer. Another major red flag is describing a technical task instead of a user-facing feature, for example, 'As a developer, I want to add an index to the users table...'. This is a task, not a story, because it delivers no direct user value. Also, writing vague, untestable ACs like 'the process should be fast' or 'the UI should be intuitive' demonstrates a lack of rigor. A story is not a complete specification; a candidate who forgets the 'Conversation' and treats the card as a final, rigid document is missing the point.

LIKELY FOLLOW-UPS: Expect questions like 'How do you handle a story that is too big for a single sprint?' (Answer: Split it vertically along user-facing functionality). Or, 'What is the difference between an Epic and a User Story?' (An Epic is a large feature that is broken down into multiple smaller stories). 'Who is responsible for writing user stories?' (The Product Owner is responsible for the backlog, but anyone on the team can and should contribute to writing them).

ONE CONCRETE EXAMPLE: STORY: As a logged-in customer, I want to add an item to my shopping cart so that I can purchase it later. ACCEPTANCE CRITERIA: Given I am viewing a product page and my cart is empty, when I click 'Add to Cart', then the cart icon's counter updates to '1'. Given an item is already in my cart, when I add the same item again, then the quantity of that item in the cart increments by one, and the cart total is recalculated. Given I am not logged in, when I click 'Add to Cart', then I am prompted to log in or continue as a guest.