User Story Generator

TL;DR: A user story is a one-sentence requirement written from the user’s side: who needs something, what they want to do and why. Add two or three acceptance criteria in Given / When / Then, an estimate and a MoSCoW priority, and a developer can pick it up without a meeting. This generator gives you the template, five ready sets of stories, an INVEST check and a CSV that Jira imports as Story issues.

It is built for founders, product owners and analysts who need a backlog before hiring a team. Stories written this way are also the fastest input for an estimate: if you are planning MVP development or a longer product engineering engagement, send us the backlog and we will come back with an estimate within one business day.

The generator works in four steps, and everything stays in your browser:

1. Product. Name the product, choose story points or T-shirt sizes and write one Definition of Done for all stories.
2. Set. Pick a starting set: online store, food delivery, fitness app, SaaS account or marketplace, eight stories each. Or start empty.
3. Stories. Edit roles, actions, values, criteria, estimates, priorities and epics.
4. Check. Review the INVEST warnings, then export to CSV for Jira, DOCX, Markdown or PDF.

There is no AI writing in this version. You start from a template or a ready set and change it, so the stories describe your product rather than a generic one.

What does a good user story look like?

A good user story names a specific role, one action and a value you could defend in a budget meeting: “As a [role], I want to [action] so that [value]”. Here is a complete example for an online store:

Story: As a returning customer, I want to repeat a past order in one tap so that I don’t rebuild my cart from scratch.

• Given I am signed in and have a completed order, when I tap “Reorder” on it, then all items that are in stock are added to my cart in the same quantities.
• Given one item from that order is out of stock, when I tap “Reorder”, then the other items are added and I see which one was skipped.
• Given my cart already has items, when I reorder, then the new items are added to the existing cart, not swapped for it.

Estimate: 3 points (M). Priority: Should. Epic: Orders.

The story leaves out buttons, tables and API names: those are team decisions. If you can’t fill in the “so that” part, ask whether the feature is needed at all.

How do you write acceptance criteria in Given / When / Then?

Write one criterion per scenario: Given is the state before the action, When is the action, Then is a result someone can check without asking you. Start with the main path, then add the cases that usually break in production: empty data, errors, no permission, a lost connection. Three to five criteria is a sensible range. If you need more than six, the story is probably two stories.

Acceptance criteria are not the same as the Definition of Done. Criteria belong to one story (“skipped items are listed”); the Definition of Done applies to every story (“code reviewed, tests pass, deployed to staging”), and the generator asks for it once, on the first step. QA can turn each Given / When / Then line straight into a test case.

What does INVEST mean, and what does the generator check?

INVEST is a six-point quality check. The generator flags what it can detect; the rest is for the team.

How should you estimate and prioritise user stories?

Use the relative scale 1, 2, 3, 5, 8: points compare stories with each other, they are not hours. T-shirt sizes are quicker for a first pass; the generator stores them as points (XS = 1, S = 2, M = 3, L = 5, XL = 8) so the Jira column stays numeric.

MoSCoW sorts the backlog into Must, Should, Could and Won’t (this time). For a first release, keep the Must group small enough that it alone delivers something usable. Won’t is useful too: it records what you agreed to leave out.

How do you import user stories into Jira?

Download “CSV for Jira”, then in Jira open System → External system import → CSV and map the columns. One story per row:

• Summary — the action, short enough for a board card;
• Description — the full “As a… I want… so that…” sentence plus numbered acceptance criteria;
• Issue Type — always Story;
• Story Points — 1 to 8;
• Epic Link — the epic name; create the epics first or use existing keys;
• Labels — the MoSCoW priority (moscow-must, moscow-should…) and, for T-shirt sizing, the size.

In team-managed projects map the epic to Parent instead of Epic Link.

Where do user stories fit next to a PRD and an RFP?

Stories describe behaviour; the documents around them describe context. A product requirements document adds goals, scope, non-functional requirements and risks, and you can draft one with the spec generator. If you are hiring an outside team, attach the backlog to a request for proposal built with the RFP generator, then compare the replies in the vendor scorecard. Vendors who estimate the same stories are much easier to compare than vendors who each guessed at a vague brief.

FAQ

Related tools