Gera Tools

User Story Builder

Write properly formatted user stories with As-a, I-want, So-that

Generate well-formed agile user stories in the As-a / I-want / So-that format with acceptance criteria, story points and a linked epic — ready to paste into Jira, GitHub Issues or your backlog. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the As-a / I-want / So-that format?

It's the standard agile user-story template: 'As a [role], I want to [action], so that [benefit].' It keeps stories focused on a user and their goal rather than on implementation details.

Stories that pass refinement on the first try

Backlog items fail refinement when they describe a feature without a user, a goal or a way to verify completion. This builder enforces the As-a / I-want / So-that structure and pairs it with acceptance criteria and a point estimate, so every story you write is ready, testable and estimable.

How it works

You fill three clauses — the role, the action and the benefit — and the tool composes the canonical sentence “As a [role], I want to [action], so that [benefit].” You then add acceptance criteria one per line (Given / When / Then works best), pick a story-point estimate from a Fibonacci scale, and optionally name an epic. The builder outputs a complete story block with the formatted sentence, a bulleted acceptance-criteria list, the point estimate, the epic, and a short definition-of-ready checklist to confirm the story is genuinely sprint-ready.

Tips and example

A good story reads end-to-end: “As a returning customer, I want to save items to a wishlist, so that I can buy them later without searching again,” with acceptance criteria like “Given I am logged in, when I tap the heart icon, then the item is added to my wishlist.”

  • Keep the benefit user-focused — “so that” should describe a real outcome, not a restatement of the action.
  • Write acceptance criteria you can turn directly into tests.
  • If a story is hard to point or has more than a handful of acceptance criteria, split it.

Common user story mistakes — and how this builder prevents them

The “system” as the user. Stories that begin “As a system, I want to…” are not user stories — they are technical tasks. The role in “As a [role]” should always be a person who gets value from the feature. If no user benefits, the work is technical debt or infrastructure, which belongs in a different backlog category, not a user story.

Vague benefits. “So that I can use the feature” adds nothing. The benefit should express genuine user value: “so that I don’t have to re-enter my address each time” or “so that I can see at a glance whether my order shipped.” Vague benefits signal that the story hasn’t been thought through and make prioritization against other stories impossible.

Stories that are really epics. If a story takes more than a sprint to deliver, requires more than 8 story points, or has more than 6–7 acceptance criteria, it is almost certainly an epic in disguise. Break it into smaller stories that each deliver independent value. The Fibonacci scale this builder offers (1, 2, 3, 5, 8, 13) serves as a forcing function — a 13-point estimate is a signal to split, not a target.

Missing acceptance criteria. A story without acceptance criteria forces each team member to interpret “done” independently, which guarantees a rework loop after the sprint review. Even two or three clear criteria are dramatically better than none.

Connecting stories to the epic and roadmap

Naming an epic in each story is more than organizational tidying. It serves three planning purposes:

  1. Capacity planning: Grouping stories by epic shows which initiatives are consuming most of the team’s capacity in a given sprint or quarter.
  2. Dependency mapping: Stories in the same epic often share dependencies; naming the epic surfaces those relationships without requiring a separate dependency tracking exercise.
  3. Roadmap communication: Stakeholders understand epics as features or initiatives better than they understand individual stories. When you show a sprint plan that includes stories tagged to “Checkout redesign” and “Mobile notifications,” a non-technical stakeholder immediately understands what the team is working toward.

Estimation with the Fibonacci scale

The Fibonacci scale (1, 2, 3, 5, 8, 13) is used rather than a linear scale because effort estimates are inherently uncertain, and the larger gaps at higher numbers honestly represent that uncertainty. The difference between a 1-point story and a 2-point story is small and reasonably well-understood. The difference between an 8-point and a 13-point story is large and reflects genuine unknowns. Teams that use a linear 1–10 scale tend to cluster estimates in the middle and avoid the extremes — the Fibonacci scale counteracts that bias.