User Story

Purpose

Create clear, concise user stories that combine Mike Cohn's user story format with Gherkin-style acceptance criteria. Use this to translate user needs into actionable development work that focuses on outcomes, ensures shared understanding between product and engineering, and provides testable success criteria.

This is not a feature spec—it's a conversation starter that captures who benefits, what they're trying to do, why it matters, and how you'll know it works.

Key Concepts

The Mike Cohn + Gherkin Format

A user story combines:

Use Case (Mike Cohn format):

• As a [user persona/role]
• I want to [action to achieve outcome]
• so that [desired outcome]

Acceptance Criteria (Gherkin format):

• Scenario: [Brief description of the scenario]
• Given: [Initial context or preconditions]
• and Given: [Additional preconditions]
• When: [Event that triggers the action]
• Then: [Expected outcome]

Why This Structure Works

• User-centric: Forces focus on who benefits and why
• Outcome-focused: "So that" emphasizes the value delivered, not just the action
• Testable: Gherkin acceptance criteria are concrete and verifiable
• Conversational: Story is the opening for discussion, not the final spec
• Shared language: Product, engineering, and QA all understand the format

Anti-Patterns (What This Is NOT)

• Not a task: "As a developer, I want to refactor the database" (this is a tech task, not user value)
• Not a feature list: "I want dashboards, reports, and analytics" (this is too big—needs splitting)
• Not vague: "I want a better experience" (unmeasurable, no clear outcome)
• Not a contract: Stories are placeholders for conversation, not locked-in specs

When to Use This

• Translating user needs into development work
• Backlog grooming and sprint planning
• Communicating value to engineering and design
• Ensuring testable acceptance criteria exist before development