User Stories & Acceptance Criteria

Once a team knows what's needed, it has to write it down in a way developers can build and everyone can agree on. Agile teams do this with user stories — short, plain sentences written from the user's point of view — each paired with acceptance criteria that say exactly when it's done.

The format keeps the focus where it belongs: on a real person trying to achieve something, not on a feature for its own sake. It's deliberately small and conversational — a reminder to have a discussion, not a thick specification document.

Think of a restaurant order ticket: who it's for, what they want, and how the kitchen will know it's right. A user story is that ticket for a piece of software.

The Story Format

User stories follow a simple template: "As a [type of user], I want [some goal], so that [some benefit]." The three parts force you to name who it's for, what they want, and why it matters. That "so that" is the secret weapon — it keeps the team honest about the actual benefit, and sometimes reveals that the requested feature isn't the best way to deliver it.

Acceptance Criteria

Acceptance criteria are the specific, checkable conditions that define "done" for a story. They turn a friendly sentence into something testable: not just "I want a reminder", but "the reminder fires at the chosen time, tapping it opens the app, and reminders are off by default". When every criterion is met, the story is done — no debate. They're also the seed of the tests that will later verify the feature, tying requirements straight to testing.

INVEST: What Makes a Good Story

Good user stories share a set of traits captured by the word INVEST: Independent (stands on its own), Negotiable (a starting point for discussion, not a contract), Valuable (delivers something a user cares about), Estimable (the team can size it), Small (fits in a sprint), and Testable (you can tell when it's done). You don't need to recite it — just know that a good story is small, valuable, and clearly finishable.

Stories, Tasks, and Epics

Work comes in sizes. A big, vague chunk of value — "users can manage their habits" — is an epic; it's too large to build directly, so it's split into several stories ("create a habit", "edit a habit", "delete a habit"). Each story may then break into developer tasks (the technical steps to build it). Epic splits into stories, stories split into tasks — a simple hierarchy you'll see on every Agile board.

For Cadence, Priya writes: "As a user, I want a daily reminder so I don't forget my habit," with acceptance criteria — fires at the chosen time, tappable to open the app, off by default. Now Lena knows exactly what to build, Nora knows exactly what to test, and Priya knows exactly what "done" looks like. One small sentence aligns the whole team.