The user story template
User stories came out of Extreme Programming as a lightweight alternative to long requirement documents. The standard format, often called the Connextra template, has three parts, and each one forces a decision that vague tickets skip.
The template is a tool, not a rule. If you catch yourself writing “As a developer, I want to refactor the auth module,” it’s probably a task, and it’s fine to write it as one.
- As a [type of user]: who benefits. Be specific: “workspace admin” beats “user.”
- I want [capability]: what they can do once the story ships. Describe the outcome, not the UI or the code.
- So that [benefit]: why it matters. This clause lets the team propose a simpler way to get the same result.
How to write a good user story
Start from a real problem, ideally one you heard from a customer or saw in support tickets. Then work through these steps:
- Name a specific user and a specific outcome.
- Keep it to one behavior. If the story needs an “and,” consider splitting it.
- Add acceptance criteria that a tester could mark as pass or fail.
- Size it so the team can finish it in a few days, well inside one sprint.
- Talk it through in refinement. The written story is a reminder of a conversation, not a replacement for one.
The INVEST checklist
Bill Wake’s INVEST acronym is a quick test for whether a story is ready to plan. A story that fails one of these usually needs splitting or more conversation.
- Independent: can be built and shipped without waiting on another story.
- Negotiable: describes the need and leaves room to discuss the solution.
- Valuable: delivers something a user or customer would notice.
- Estimable: the team understands it well enough to size it.
- Small: fits comfortably in one sprint.
- Testable: has clear criteria for pass or fail.
User story vs requirement
A traditional requirement states what the system must do, such as “The system shall export invoices as PDF.” It aims to be complete and precise up front, and it’s often signed off before work starts.
A user story states who needs what and why, and leaves the details to a conversation between product, design and engineering. The precision arrives later, through acceptance criteria written during refinement. Stories trade upfront completeness for faster feedback. Many teams use both: a product requirements document for the big picture, broken into stories for delivery.
Who writes user stories
In Scrum, the Product Owner is accountable for the Product Backlog, so they usually write or approve stories. In practice, good stories come from anyone close to the problem: designers, developers, support and customers. What matters is that the team refines each story together before it enters a sprint, so everyone agrees on what it means and how it will be tested.
Writing the first draft is the easy part. The harder part is splitting. A story that starts as “manage invoices” often becomes four or five smaller stories once the team talks through roles, rules and edge cases, and that splitting is a big part of what refinement is for.
User story in NoaBox
Attach a PRD, spreadsheet or CSV in Ask Noa and it drafts work items with priorities and acceptance criteria as proposals. Nothing is created until someone on your team reviews and confirms each one, so you stay in charge of how stories are worded and split.
See how Noa works