Scrum: What Makes a User Story Good

Once, during a job interview, I was asked what a perfect user story looks like. I didn't have a clean answer, because I had never seen a book example survive contact with a real backlog. Every good story I'd actually shipped against was good for reasons specific to the feature, not because it matched a template.

This is the answer I'd give now. It covers why "perfect" is the wrong target and INVEST is a diagnostic rather than a recipe, what a story leaves out on purpose, the acceptance criteria that turn a one-liner into something a team can actually estimate, and the failure mode that produces stories which pass every INVEST check and are still useless.

Why "perfect" is the wrong target#

INVEST, independent, negotiable, valuable, estimable, small, testable, is the checklist everyone quotes, and it is a good one. It is also a checklist for ruling stories out, not a recipe for writing one in. A story can satisfy all six letters and still fail, because INVEST says nothing about whether the story's acceptance criteria actually constrain the feature enough for two developers to build the same thing from it independently.

As a frequent traveler, I want to view my flight itinerary on my phone, so I can access it on the go.

That story is independent, negotiable, valuable, small, and probably estimable. It is not testable yet, because "view my itinerary" has no stated boundary. Offline access? Which fields show? What happens with a connecting flight across two bookings? A story this thin passes INVEST and still sends two developers down different implementations.

What the story is supposed to leave out#

The usual complaint about thin stories is "add more detail," which is the wrong fix. A user story is deliberately not a specification. It names the who, the what, and the why, and defers the exact how to the team that builds it, in conversation, during planning. The INVEST letter doing the real work here is "negotiable": the story is a placeholder for a conversation, not a contract that substitutes for one.

As a <role>, I want <capability>, so that <benefit>.

Acceptance criteria:
  - Given <context>, when <action>, then <outcome>
  - Given <context>, when <action>, then <outcome>

The first line stays short on purpose. The acceptance criteria underneath it carry the weight that "view my itinerary" was missing: given a connecting flight across two bookings, when the itinerary loads, then both legs show under one trip card. That line is the difference between a story a developer can build from and a story they have to come back and ask about, and it is the part that is actually missing from most "perfect user story" examples, including the one I gave in that interview.

Small is a constraint on the team, not the feature#

"Small enough to complete in a sprint" sounds like a size rule for the feature. It is actually a constraint on how the team slices it. A big feature does not fail INVEST, it gets sliced into several small, independently valuable stories, each shippable on its own. "Add payment support" is not a story, it is an epic hiding behind one sentence. "A customer can pay with a saved card" and "a customer can remove a saved card" are stories, and each one is independently negotiable, estimable and testable without waiting on the other.

The question that actually matters#

Before a story goes into a sprint, I ask whether two developers who have not talked to each other could read it, including the acceptance criteria, and build something that passes the same tests. If the answer is yes, the story has done its job, regardless of how closely it resembles the template. If the answer is no, more acceptance criteria fix it faster than a better first sentence does.