How to Use
Select the type of user or role - for example, logged-in user, admin, guest, or a specific persona.
Describe the feature or action the user wants to perform in plain language.
Describe the benefit or goal - why the user wants this feature, what outcome it enables for them.
Review the generated user story in As a / I want / So that format.
Add three to five acceptance criteria in Given/When/Then format to define what done looks like for this story.
What Is This Tool?
User stories are lightweight requirements written from the user's perspective in the format: As a [type of user], I want [action or feature], so that [benefit or goal]. Good user stories satisfy the INVEST criteria: Independent (can be developed and released separately from other stories), Negotiable (implementation details are open to discussion between the team and stakeholders), Valuable (delivers real value to the user or business), Estimable (can be sized by the team), Small (fits within a single sprint), and Testable (acceptance criteria can be verified by a tester). A user story is distinct from a task (which describes implementation work, not user value) and from a bug (which describes a deviation from expected behavior). The story format keeps the team focused on user outcomes rather than technical implementation details.
Why It Matters
Poorly written user stories are the most common cause of sprint failure. Stories that conflate implementation details with user outcomes (such as 'as a user I want a database index' - this is a technical task, not a user story), stories without acceptance criteria, and stories too large to fit in a sprint all create ambiguity that derails development. When developers do not understand why a feature exists, they make implementation decisions that miss the user's actual need. Good stories make estimation accurate and acceptance testing straightforward because the team and the tester are working from the same definition of done.