User story format guide: the complete reference with examples

The user story format is a constraint, not a formula. The specific words "As a, I want, so that" matter less than what they force: a named user, a specific action, and a measurable outcome. Teams that understand the constraint produce better stories than teams that fill in the template without understanding why. 68% of engineering re-requests trace back to user stories that were written without the right level of specificity (Scriptonia, 2026).

"I can tell how good a PM is from their user stories in two minutes. Vague personas, activity-level actions, and absent acceptance criteria are all signals. Not because the format is sacred, but because getting the format right forces the thinking."

— Lena K., Engineering Director at a product-led growth company

The standard Connextra format

As a [role], I want [feature/action] so that [benefit/outcome].

The three parts:

• Role: Who specifically benefits? Not "user", an actual role with context. "Admin managing a 10+ person team", "New user in their first session", "Enterprise customer with SSO enabled".
• Feature/action: What the user does, not what the system does. Observable behavior, not internal logic. "Export activity as CSV", not "access data export".
• Benefit/outcome: Why this matters. The outcome the user achieves, not the feature value. "Share usage reports without creating new accounts", not "save time".

BDD format (Behavior-Driven Development)

BDD stories use Gherkin syntax: Given / When / Then

This format is used directly in automated testing tools (Cucumber, SpecFlow) and produces acceptance criteria as a byproduct:

Feature: CSV Export
  Scenario: Admin exports activity report
    Given I am logged in as an admin with Export permission
    When I select a 30-day date range and click "Export CSV"
    Then a CSV file downloads with columns: User, Action, Timestamp
    And the file contains one row per activity event in the range

INVEST criteria for story quality

Letter	Criterion	Test
I	Independent	Can this story be built and tested without depending on another story?
N	Negotiable	Is there room to discuss implementation approach?
V	Valuable	Does this deliver user or business value on its own?
E	Estimable	Can engineers give a story point estimate?
S	Small	Can this be completed in one sprint?
T	Testable	Does it have acceptance criteria a QA engineer can verify?

Story size: when to split

Split a story when: it takes more than 5 sprint days to implement, it has more than 7 acceptance criteria, it covers more than one user role, or it contains "and" in the action component ("create AND manage AND delete"). Each split produces smaller, independently-shippable stories.