What user story details reveal the customer problem?
This tests if you see stories as problem placeholders, not specs. A strong answer asks for user role, action, 'so that' value, and confirmation criteria while demanding conversation. Red flag: listing technical tasks without mentioning the customer problem.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Which set of details best shows a user story is a placeholder for a customer problem rather than a technical specification?
- a.API contracts, database schemas, and UI mockups
- b.Rigid templates and mandatory JIRA fields for structure
- c.Technical acceptance criteria such as deploying a service or adding a database column
- d.A specific user role, the desired user action, a 'so that' justification, and confirmation criteria tied to observable outcomesCorrect
Why? this is the answer
A strong user story requires the user role, the action they need, the 'so that' value, and confirmation criteria that validate the problem is solved. Option A is tempting because technical specs feel like thorough requirements, but they transform the story into a design document rather than a placeholder for conversation.
Just read this? Test yourself on what you have been reading.
Read the original → resources.scrumalliance.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles