User story
A user story with acceptance criteria that can be tested: who it is for, what they can do, and the conditions a tester could check without asking a question. Written from what you already know, in the format your team already uses.
- Asks for
- What the user should be able to do, and why
- Anything you already know about rules, limits or the current behaviour
- How your team writes criteria, if you have a house style
- Gives back
- The story, in your team’s format
- Acceptance criteria written as checkable conditions
- The edge cases people skip: empty, invalid, repeated, interrupted
- What the story leaves undecided, named rather than assumed
- Plan
- Free
- Use next
- Epic, Document to tickets, FRD
What it gives you
As a PM with a backlog in a spreadsheet, I can import it as CSV so that I can rank it without retyping anything. Acceptance criteria 1 Given a CSV with a header row, when I import it, then columns are matched by name and I am shown the match before anything is saved. 2 Given a column that cannot be matched, then I am asked about that column only, and the rest stay matched. 3 Given a file of more than 500 rows, then the first 500 import and I am told how many were left.
How it works
The as-a-I-want-so-that sentence is the part everyone remembers and the least important part of a story. What decides whether the story is any good is the acceptance criteria: if they are testable, the story is buildable; if they say the feature should work correctly, it is a conversation that has not happened yet.
So the criteria are written as conditions with a trigger and a result, including the ones people skip — what happens with no data, with bad data, with the action done twice. A criterion a tester has to interpret is a criterion that will be interpreted differently by the person who wrote it and the person who tests it.
It also writes in your format. If your team puts criteria in given-when-then, or as a checklist, or demands a note on the non-functional side, say so once and the stories come out that way, which matters because a story that does not look like the others gets rewritten by hand.
Who it is for
A PM or BA writing stories for a sprint who wants them to pass refinement without three rounds of questions.
Where it stops
One story at a time. If you have a document to break down, Document to tickets does the whole thing at once and keeps the stories consistent with each other, which a story written one at a time will not be.
Questions people ask
What makes an acceptance criterion testable?
It names a trigger and a result that somebody could observe without judgement. "The import handles errors gracefully" is not testable — two people will disagree about gracefully. "Given a row with a missing effort value, the row is kept and listed under needs a value" is: you can do it and look. The quickest check is to ask whether a tester could get it wrong and be sure they were right.
How many acceptance criteria should a story have?
Enough to cover the behaviour and no more, which in practice is usually three to seven. One criterion usually means the story is a task; fifteen usually means it is two or three stories that should be split so they can be released separately. The edge cases count: a story with four happy-path criteria and nothing about empty or invalid input is not finished, it is optimistic.
Can it write stories in my team’s format?
Yes. Tell it once how your team writes them — given-when-then, a plain checklist, a required note on performance or accessibility — and the stories come out in that shape. This matters more than it sounds: a story that does not look like the others on the board gets rewritten by hand in refinement, which costs more time than writing it from scratch would have.
Run it on your own work
User story needs an account, because it writes against what you give it and remembers what you have told it before. It runs on the Free plan. Or see what the plans cost first.