What is a User Story?
User Story
A user story is a short description of a feature written from the perspective of the person who will use it, stating what they need and why.
A user story is a short, plain-language description of something a person needs from a product, written from that person's point of view. The most common format, popularized by Mike Cohn in his 2004 book User Stories Applied, is: "As a [role], I want [goal], so that [benefit]." The format keeps the focus on the outcome a person needs, not on a list of technical steps.
User stories came out of Extreme Programming in the late 1990s, where Kent Beck and Ron Jeffries pushed teams to replace long requirement documents with small, conversational descriptions of value. A user story is meant to be a placeholder for a conversation, not a finished spec. The details get worked out with the team before and during the sprint that builds it.
For a small delivery team, user stories solve a specific problem: a requirements document written once at the start of a project goes stale the moment priorities shift. A backlog of user stories can be reordered, split, or dropped week to week without rewriting a 40-page document every time something changes.
The User Story Format
The standard template has three parts: who wants it, what they want, and why it matters. Each part changes what the team builds.
"As an agency owner, I want to see which projects are over budget before the client notices, so that I can fix the problem while there's still time to act." The role tells the team who this is for. The goal tells them what to build. The reason tells them why it's worth the effort, and it often reveals a smaller or different solution than the goal alone suggests.
- Role: who is asking for this, in specific terms ("agency owner," not "user")
- Goal: the action or capability they want, stated as an outcome, not a UI element
- Benefit: why they want it, which often points to a cheaper way to solve the same problem
- Alternative format for internal or backend work: "When [situation], I want [capability], so I can [outcome]"
User Story vs Task vs Requirement
These three get used interchangeably, but they operate at different levels of detail and serve different purposes.
| Term | Describes | Written from | Fixed once written? |
|---|---|---|---|
| Requirement doc | A detailed spec, agreed upfront | The business or client | Yes, changes need a formal process |
| User story | A need, in plain language | The end user | No, refined as understanding improves |
| Task | A concrete step to deliver part of a story | The team doing the work | No, created during sprint planning |
The INVEST Criteria: What Makes a Good User Story
Bill Wake proposed the INVEST checklist in 2003 as a quick test for whether a story is ready to work on. A story that fails most of these checks needs rewriting before it goes into a sprint.
- Independent: the story can be built and delivered without waiting on another story
- Negotiable: it describes a need, not a locked specification, so the team can propose a better way to meet it
- Valuable: it delivers something a real person cares about, not an internal implementation detail
- Estimable: the team knows enough about it to size the effort, at least roughly
- Small: it fits inside a single sprint, ideally finishing in a few days
- Testable: there's a clear way to confirm it's done, usually written as acceptance criteria
Acceptance Criteria: How a Story Gets Confirmed Done
A user story states what someone needs. Acceptance criteria state exactly how the team will know it's been delivered. Without them, "done" means whatever the person who built it decided it means, and that rarely matches what the person who requested it expected.
A common format is Given/When/Then: "Given a project is over budget, when the owner opens the dashboard, then a red budget warning appears next to that project's name." Each story should carry two to five acceptance criteria. More than that usually means the story is too large and needs to be split.
- Given: the starting condition
- When: the action the person takes
- Then: the result that confirms the story works
- Two to five criteria per story; beyond that, split the story
Splitting a User Story That's Too Big
A story that can't finish inside a sprint isn't a user story, it's an epic wearing a user story's format. Splitting it keeps each piece small enough to estimate and finish, while each piece still delivers something a person can use on its own.
Four ways to split a story: by workflow step, by data type, by business rule, and by user role. Take "As an agency owner, I want to invoice clients, so that I get paid for completed work." That's too broad for one sprint. Split by workflow step: generate a draft invoice from logged hours, review and edit line items, send the invoice as a PDF, mark it as paid. Each of those is its own story, small enough to finish in one to three days, and each one is still useful to a real person on its own.
| Split method | Example | When to use it |
|---|---|---|
| By workflow step | Draft invoice -> edit lines -> send -> mark paid | The original story has a clear sequence of actions |
| By data type | Support CSV export before adding PDF export | The story covers multiple formats or data sources |
| By business rule | Handle the standard case before edge cases like partial refunds | The story bundles a common path with rare exceptions |
| By user role | Owner view before member view of the same screen | The same feature behaves differently per role |
User Stories in Practice: A 10-Person Team Example
Lindgren Studio, a 10-person digital agency, decided to build a client portal add-on for their internal tool. Instead of writing a single spec titled "Build the client portal," the project lead and two developers spent 90 minutes converting the idea into a backlog of stories.
The first draft had one giant story: "As a client, I want a portal where I can see everything about my project." That failed the Independent and Small checks in INVEST immediately. The team split it into eight stories: view project status, view completed milestones, download final files, view and pay open invoices, message the account manager, view the project timeline, receive a notification when a milestone completes, and reset a forgotten password.
Each story got two to four acceptance criteria and a rough estimate in hours. Six of the eight fit into a single two-week sprint. The remaining two, invoice payment and messaging, needed a payment integration and got pushed to sprint two, once the team confirmed clients used the portal at all before investing in the harder pieces.
The habit that made this work: nobody wrote a story about a button or a database table. Every story named a person and a reason, which kept the backlog focused on what clients would get, not on how the screen would be built.
- One vague feature idea split into 8 stories, each independently shippable
- 2 to 4 acceptance criteria per story, agreed before estimating
- 6 of 8 stories fit sprint one; the 2 hardest waited for validation that clients would use the portal
- Every story named a role and a reason, never a UI element in isolation
Writing User Stories in Melororium
Melororium doesn't enforce a rigid Scrum artifact structure. Teams write user stories as task titles in the Tasks module, using the "As a... I want... so that..." format in the task name or description, then add acceptance criteria as a subtask checklist so each one can be checked off individually.
Tags separate story types (feature, bug, internal) and priority fields carry into the sprint-style board view. Because time tracking lives on every task, teams can compare the estimate written at splitting time against the hours a story took, which makes the next round of story sizing more accurate.
Available in every plan starting at $29/mo for 4 users. No separate backlog tool required.
In Melororium
Turn user stories into tasks in Melororium
Common mistakes with user story
What teams get wrong most often, and what to do instead.
- 1
Writing the story from the builder's point of view
"As a developer, I want to refactor the API" isn't a user story, it's a task with a template pasted around it. A real user story names the person who benefits from the work being live, not the person doing the work.
- 2
No acceptance criteria attached
Marking a story done with nothing written down about what "done" means. The result gets reviewed against whatever the reviewer assumes, which rarely matches what the requester pictured.
- 3
Writing the backlog once and treating it as fixed
Filling the backlog at kickoff and never revisiting the stories as the team learns more. A story written before anyone touched the problem is a guess, and guesses need updating.
- 4
Treating story points as hours
Assigning a story 5 points, then billing or scheduling exactly 5 hours against it. Points measure relative size and uncertainty compared to other stories on the same backlog, not a promise about the clock.
Frequently asked questions
Who writes user stories?
Usually the Product Owner or project lead drafts them, with input from designers and developers who flag what's missing or unclear before the story goes into a sprint. On small teams, whoever owns the backlog writes the first pass and the team refines it together.
How big should a user story be?
Small enough to finish inside one sprint, and ideally small enough that one person can complete it in one to three days. If a story takes longer, split it using workflow steps, data types, business rules, or user roles.
What's the difference between a user story and an epic?
An epic is a large body of work that can't fit in one sprint and gets broken down into multiple user stories. "Client portal" is an epic. "View completed milestones" is one of the stories inside it.
Do user stories replace a spec document?
For most agency and product work, yes, stories plus acceptance criteria give the team enough to build and test against. Regulated or contract-heavy projects often still need a formal spec alongside the story backlog.
Does Melororium support user stories?
Teams write stories as task titles in the Tasks module and track acceptance criteria as subtasks. There's no separate backlog tool needed, and logged time on each story feeds directly into Work Reports.
