User Stories and Acceptance Criteria: Core Methods for Agile Requirements

User Stories and Acceptance Criteria: Core Methods for Agile Requirements

User stories are the most common way to express requirements in agile and Scrum. Mike Cohn of Mountain Goat Software argues that the real value of a user story is not in the words written down, but in being a "placeholder for a future conversation." Compared with traditional requirements documents, user stories shift a team's focus from writing about features to talking about them.

The 3Cs of user stories

Ron Jeffries named the three aspects of a user story in 2001 with the alliteration card, conversation, and confirmation:

• Card: the written description of the story, used for planning and as a reminder.
• Conversation: discussions about the story that flesh out details and clarify boundaries.
• Confirmation: the tests or conditions that determine when a story is complete — in other words, the acceptance criteria.

Conversation matters more than text — a user story is incomplete until the discussions about it occur. That is also why a story living in Jira or Trello should not be any harder to discard when it is no longer needed.

Template and examples

User stories typically follow a simple template: As a , I want so that . The sentence starts from the perspective of a real user and answers "who," "what," and "why" at once. For example:

• As a site visitor, I want to filter articles by category so that I can quickly find topics that interest me.
• As a customer, I want to submit a ticket online so that I can get support without sending email.

Note that the protagonist should be an end user or customer, not the product owner — "As a product owner, I want a list of articles" points in the wrong direction.

From mediocre to solid: a rewrite example

Comparing two versions makes the gap obvious. “As a user, I want to see a list of articles so that I can browse” — the role is vague (visitor or logged-in user?), the goal is empty, and there is no reason. Rewritten as “As an anonymous visitor, I want to filter the article list by category and tag so that I can quickly find content I care about among hundreds of posts,” the direction becomes clear immediately. What really separates the two is the acceptance criterion: “Filtering by category should produce a shareable URL with a query parameter (e.g., ?cat=ai).” Add that line and dev, QA, and product agree exactly on what “done” means.

Epics and splitting

User stories can be written at varying levels of detail, from large epics to small distinct features. Large stories have less detail and generally cannot be completed in a single iteration, so they are split into smaller stories before work begins. For example, "As a user, I can back up my entire hard drive" could be split into "As a power user, I can select files to back up by size" and "As a user, I can exclude folders from backup." Splitting is the first way to add detail to a story.

Acceptance criteria: conditions of satisfaction

The second way to add detail is through conditions of satisfaction — the acceptance criteria. These are high-level acceptance tests that must all be true for the story to be complete. For example, "As a vice president of marketing, I want to select a holiday season for reviewing past campaigns" could add:

• Work with major retail holidays: Christmas, Thanksgiving, New Year's Day, and so on.
• Support holidays that span two calendar years.
• Holiday seasons can be set to a number of days prior to the holiday.
• Holiday seasons can run from one holiday to the next.

Writing clear acceptance criteria fixes "what done means" in the discussion and prevents rework.
Beyond a “conditions of satisfaction” list, many teams write acceptance criteria as runnable scenarios using Given/When/Then:

This format is tighter than a one-line description and much easier to turn into automated tests.

A quality checklist: INVEST

To judge whether a story is well written, the industry often uses the INVEST acronym: Independent, Negotiable, Valuable, Estimable, Small, Testable. The most overlooked is T — a story without acceptance criteria cannot be tested, so “done” can never be confirmed. Run every story past this checklist and it will catch most low-quality items.

Who writes stories and when

Anyone can write a user story. The product owner is responsible for ensuring a product backlog exists, but does not have to write every story; on a good agile project, stories are written by each team member. A story-writing workshop is usually held near the start of the project to create a backlog covering the whole project or a three-to-six-month release cycle, and new stories can be added at any time by anyone.

The backlog can be thought of as a replacement for the traditional requirements document, but the written part ("As a user, I want...") is incomplete until the discussions happen. When useful, a story can point to a diagram of a workflow, a spreadsheet showing a calculation, or any artifact the team desires.

Connecting with the AI era

Acceptance criteria and the AI-era evaluation dataset share the same idea: turning "what good looks like" into runnable conditions. The former fits deterministic software; the latter fits AI outputs. For AI features, express the intent as a story and define "good output" with an eval set — they complement each other. After launch, virtual user testing can quickly check whether the acceptance criteria are truly being met between iterations.

16IDC perspective

For website and SaaS teams, the value of user stories is in moving requirements from "description" to "discussion and acceptance." Whether a story is well written depends less on the template and more on whether there is ongoing conversation and clear completion conditions. For the full analysis workflow, see the Requirements Analysis category on this site.

Source: https://www.mountaingoatsoftware.com/agile/user-stories
Reference: Atlassian — User Stories https://www.atlassian.com/agile/project-management/user-stories