User story prompt builder
Well-formed user stories are the backbone of an Agile backlog, but writing them consistently — with the right persona, a clear benefit, and testable acceptance criteria — is tedious. This builder turns a feature description and a few inputs into a prompt that produces a complete user story in As-a / I-want / So-that format, plus INVEST-aware, Given-When-Then acceptance criteria your team can hand straight to QA.
How it works
You describe the feature, name the user persona, set a priority, list edge cases to cover, and choose how many acceptance criteria you want. The builder writes a prompt that instructs the model to produce the story in the standard template, keep it small and independent, derive a clear benefit, and write each acceptance criterion as a Given-When-Then scenario covering both the happy path and the edge cases you listed. It also asks the model to flag if the story is too large and should be split. Everything is assembled in your browser; you copy and run it.
The As-a / I-want / So-that structure and how to fill it well
The three-part user story format encodes who, what, and why in a single sentence. Each part has a distinct job:
- As a [persona]: Names the user — not a system role, but a person with a context. “As a project manager reviewing late deliverables” is more useful than “as a user” because the persona’s context constrains the correct behavior.
- I want [capability]: States the functional need — what the user is trying to accomplish, not how to implement it. “I want to filter tasks by due date” describes a need; “I want a date-range picker component” describes an implementation. The capability belongs here, not the solution.
- So that [benefit]: Names the outcome — why this matters to the user and the business. This is the acceptance bar. If the implementation achieves the benefit, the story is done.
Writing Given-When-Then acceptance criteria
Each acceptance criterion should be directly testable by a QA engineer. The Given-When-Then structure ensures this:
- Given sets the precondition (system state, user state, data present)
- When describes the action the user takes
- Then states the observable outcome
For example, for a login error scenario:
Given the user enters an incorrect password three times,
When they submit the login form,
Then their account is temporarily locked and a reset email is sent.
This is testable: a QA engineer can run exactly this sequence and verify the outcome. Vague criteria like “the user sees an appropriate error” cannot be tested unambiguously.
When to split a story
The INVEST principle’s “Small” criterion means a story should be completable within a single sprint. The prompt flags when a story is likely too large and suggests a split. Common signals:
- More than six acceptance criteria (usually indicates two separate behaviors)
- Acceptance criteria spanning more than two user roles
- The capability part of the story contains “and” (two features in one)
The model will suggest natural split points when it sees these. Taking the split keeps estimation reliable and scope bounded.
Tips and notes
- Name a real persona. “As an admin reviewing flagged accounts” yields sharper criteria than “as a user.”
- List the edge cases. This is where the prompt earns its keep — empty states, errors, and permission boundaries.
- Keep stories small. If the model suggests a split, take it; large stories break estimation and often hide unclear requirements.
- Given-When-Then is testable. Each criterion maps to an automated or manual test, closing the loop with QA.