user-story

User Story — Write Well-Defined User Stories Using the Mike Cohn Format and Gherkin Acceptance Criteria

Skill Overview

User Story is a product manager component skill that combines Mike Cohn’s user story format (As a / I want to / so that) with Gherkin acceptance criteria (Given / When / Then) to quickly transform user needs into development-ready, testable user stories.

Applicable Scenarios

Backlog Refinement and Sprint Planning: Quickly draft standardized user stories before iteration planning so that product, engineering, and QA can discuss requirements using a common language.

Converting PRD Requirements into User Stories: Rewrite a functional description from a product requirements document into a development-ready story that includes a role, motivation, and verifiable acceptance criteria.

Writing Requirements with Acceptance Criteria for New Features: For example, clearly define “who benefits, what they want to do, why they want it, and what counts as complete” for new features such as notification systems or login methods in B2B SaaS applications.

Core Features

Mike Cohn Use Case Format: Structure use cases as “As a [role], I want to [action], so that [desired outcome],” forcing a focus on who benefits, what they want to do, and why it is valuable, rather than merely restating feature points.

Gherkin Acceptance Criteria: Use Given (preconditions) / When (triggering event) / Then (expected result) to write acceptance criteria. Multiple Given clauses may be combined, but a single When and a single Then should be maintained to ensure that QA can directly use them to write test cases.

Quality Checks and Anti-Pattern Reminders: Built-in reminders for common mistakes—such as using “As a user,” which is too vague; having “so that” merely repeat “I want to”; using multiple When/Then clauses, which indicates that the story is too large and should be split; or writing Then clauses that cannot be measured—help you create stories that comply with the INVEST principles.

Frequently Asked Questions

What is the difference between a user story and a PRD?

A PRD is a relatively complete functional specification, whereas a user story is the opening line of a conversation: it explains in one or two sentences who wants what under which circumstances and why, then uses Gherkin acceptance criteria to define what counts as complete. This skill is intended to convert requirements from a PRD into this lightweight, testable story format, not to replace the PRD.

When should a user story be split?

When the acceptance criteria contain multiple When or Then clauses, it usually indicates that a single story combines multiple features and should be split. In addition, if a story cannot be completed within a single iteration or cannot be validated through testing, it should also be split before entering development.

Why is it problematic to start a story with “As a user”?

“User” is too vague, as the needs of different roles can vary significantly. Use a specific role or persona instead, such as “as a trial user,” “as a paid subscriber,” or “as an administrator.” This allows the story to accurately reflect the actual user motivation and makes the acceptance criteria easier to define precisely.

What is this skill not suitable for?

Purely technical debt or refactoring work has no direct user value and should be handled as engineering tasks rather than user stories. Before the user problem is understood, you should first write a problem statement and then return to writing the story.