User stories examples: format, INVEST and acceptance criteria
User stories examples with INVEST and Given-When-Then acceptance criteria: the format, a hypothetical table of 3 stories, splitting and common mistakes.
A user story is a short description of desired functionality, told from the perspective of the person who wants it and usually written as "As a [user], I want [goal], so that [reason]". Acceptance criteria are the details that show whether a story was completed correctly, often written as Given, When, Then scenarios. Bill Wake published the INVEST checklist for judging stories in 2003.
What is a user story?
A user story is a reminder to have a conversation, not a full requirement. Mike Cohn's Mountain Goat Software guide defines it as a short description of desired functionality told from the perspective of someone who wants or needs it, with the template "As a [type of user], I [need/want/am required] to [do something], so that [reason or benefit]". Its own example is a conference attendee who needs to filter sessions by topic so that the most relevant sessions are easy to find.
Ron Jeffries described stories with three words, which both Cohn's guide and Bill Wake's article repeat: card, conversation and confirmation. The card is the short written description, the conversation is where understanding grows, and the confirmation is how the team knows the story is complete, through acceptance criteria, examples or tests.
Dan North, in a 2006 article on behaviour-driven development, said the "As a, I want, so that" template was already in common use at his company. He valued it because it forces the value of a story to be stated when the story is first defined, and a story with no real value tends to end as "so that I just do".
How do you write a user story step by step?
Write the user, the need and the reason, then check the result against INVEST and split it if it is too big.
- Name the user precisely. Cohn contrasts "As a user, I want reports so that I can see information", which is vague, with a regional sales manager who needs to compare monthly revenue by territory to find where coaching is needed.
- State the need as something the user wants to do, not as a feature or screen.
- Give the reason. If no real reason exists, the story may not be worth building.
- Keep the solution out. Cohn says a story that dictates every screen, field and table before the team discusses it wastes the value of the conversation.
- Add acceptance criteria, as examples, rules or Given, When, Then scenarios, before the story enters a sprint.
- Check it against INVEST, and split it if it cannot be finished in a sprint.
Cohn adds that not everything is a story: "Create payment-token database table" is probably a task, while "As a customer, I can save a payment method so that checkout is faster next time" is a story. The stories then belong in the requirements document described in the guide to writing a PRD, and Atlassian advises linking each one to its work item and including success metrics.
What does INVEST mean in agile?
INVEST is a checklist from Bill Wake, posted on 17 August 2003, saying good stories are Independent, Negotiable, Valuable, Estimable, Small and Testable. Wake wrote that he developed the acronym himself and thanked Mike Cohn for encouragement and feedback. The table gives each letter with Wake's point and a quick check.
| Letter | Wake's point | Quick check |
|---|---|---|
| Independent | Stories should not overlap in concept and can be scheduled and built in any order | Can this be built before or after the others? |
| Negotiable | A story is not a contract for features; details are worked out by customer and developers | Does it say what and why, and leave how open? |
| Valuable | It must be valuable to the customer, so split vertically through the layers | Can a user see the benefit when it ships? |
| Estimable | The team can estimate it well enough to rank and schedule it | Does the team understand it well enough to size it? |
| Small | At most a few person-weeks of work, and some teams limit it to a few person-days | Does it fit in one sprint? |
| Testable | Writing the card carries a promise that a test could be written for it | Is there a clear pass or fail? |
Wake notes that independence cannot always be achieved, so INVEST is a prompt for judgement and not a pass mark.
How do you write acceptance criteria in Given-When-Then?
Write each criterion as a scenario: Given an initial context, When an event occurs, Then an outcome follows. Dan North described this form in 2006, using an ATM cash-withdrawal story: given the account is in credit, when the customer requests cash, then ensure the account is debited. Cucumber's Gherkin reference uses the same keywords and describes Given as the system's state before the user acts, When as an event or action, and Then as an expected outcome.
The Gherkin reference makes three useful points. It recommends 3 to 5 steps per example, because too many steps make the example lose its force as a specification. It says to avoid user interaction in Given steps. It says an outcome should be observable by the user or an external system, not a database record. Given, When, Then can be written in plain prose, with or without Cucumber.
The table shows hypothetical stories for a food-ordering app, written for a product team in Pune. The third row is deliberately too large, to show a failed check.
| Story | Acceptance criteria | INVEST check |
|---|---|---|
| As a returning customer, I want to reorder a past order so that I can repeat it without retyping it | Given an order delivered in the last 30 days, when the customer taps Reorder, then the same items appear in the basket at today's prices. Given one item is unavailable, when the customer taps Reorder, then the other items appear and a message names the missing one | Passes: small, testable, valuable |
| As a customer paying by UPI, I want a clear message when payment fails so that I know whether I was charged | Given a UPI payment that times out, when the customer returns to the app, then the order status says whether money was debited. Given a failed payment, when the customer retries, then no second order is created | Passes, but needs engineering input to estimate |
| As a customer, I want to manage saved addresses so that checkout is faster | Cannot be written as one short scenario: viewing, adding, editing and deleting each need their own | Fails Small: split it |
"Manage" in the third row is a giveaway that several operations are hiding in one story.
What is the difference between acceptance criteria and the definition of done?
Acceptance criteria belong to one story, and the definition of done applies to every item a team delivers. Cohn defines acceptance criteria as details that help the team understand whether a story has been completed correctly, which may be examples, rules, tests or brief notes. The Scrum Guide defines the Definition of Done as a formal description of the state of the Increment when it meets the quality measures required for the product, and says work cannot be part of an Increment unless it meets it.
A practical way to separate them: the reorder story's criteria say what reordering must do, while the team's definition of done says what every finished item must satisfy, such as review, passing tests and a release check. A story can meet its acceptance criteria and still not be done if the shared standard is not met. The Scrum Guide adds that an item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review, which is covered in the guide to running a sprint review.
How do you split a large user story?
Split along a vertical slice, so each piece still delivers something a user can see. Wake warns that splitting by layer, such as network, persistence, logic and presentation, leaves a database layer with little value to the customer if there is no presentation layer. Humanizing Work's guide goes further and lists nine splitting patterns: workflow steps, operations such as create, read, update and delete, business rule variations, variations in data, data entry methods, major effort, simple and complex, defer performance, and break out a spike. It says a spike should be a last resort.
Cohn says a story that cannot be finished in a sprint is usually too large, and an epic is simply a large story. Splitting the hypothetical "manage saved addresses" story by operation gives separate stories to view saved addresses, add an address, edit an address and delete one, each testable on its own. The guide's "major effort" pattern fits a payment story: when the first payment method needs new infrastructure and later ones are cheap, the first story is estimated larger, and a team can start with UPI before adding cards.
What mistakes make user stories fail?
Cohn names five common ones: treating the written story as the requirement, writing stories that are too large, splitting stories into tasks, writing every story from the product owner's perspective, and using the template without thinking. On the last point he calls the template a thinking tool and says some teams use job stories or a plain technical backlog item when that gives a better conversation.
Three more come from the sources above. A story with no reason, which North notes often reads "so that I just do", should be questioned before it is built. Acceptance criteria that mention screens and clicks make the story brittle, and the Gherkin reference advises writing examples without assumptions about technology or user interface. And criteria that are still missing when a story enters a sprint leave the team guessing, which is why Cohn says that before then the team should understand what must be true for the story to be complete.
When are user stories the wrong tool?
Stories fit user-visible behaviour and fit less well elsewhere. Cohn says not to force everything into story form, and treats some technical work as a chore, spike or task instead. A story is also only as good as the understanding behind it, which comes from customers: the guide to product discovery and customer interviews covers how a team learns what to write before it writes a story.
The format has a second limit. A well-formed story can still describe something nobody wants, and INVEST checks the shape of a story, not whether it is worth doing. Wake himself notes that the feedback cycle of proposing, estimating and implementing stories is what teaches a team what it needs to know. Treat the template and the checklist as prompts for conversation.
Where do user stories fit in a product management programme?
Certification in Product Management with Applied AI is an online programme from iHUB DivyaSampark, IIT Roorkee, run with Masai as the implementation partner, with live classes on Zoom and an optional campus immersion. It covers product discovery, prototyping with AI app builders, working with engineering teams, product metrics, designing AI features and go-to-market, and one of its modules, Working with Engineering Teams, lists APIs, user stories, Agile sprints and backlog among its topics.
Frequently asked questions
What is a user story?
A user story is a short description of desired functionality from the perspective of the person who wants it. A common template is "As a [type of user], I want [goal], so that [reason]". Mike Cohn describes the written sentence as a reminder to hold a conversation, and the real requirement emerges from that conversation.
What is INVEST in agile?
INVEST is Bill Wake's 2003 checklist for good stories: Independent, Negotiable, Valuable, Estimable, Small and Testable. It is a prompt for judgement and not a pass mark, since Wake notes independence cannot always be achieved. A story that fails several letters usually needs splitting or more conversation.
What is the difference between acceptance criteria and the definition of done?
Acceptance criteria are the conditions that show one story was completed correctly. The definition of done, in the Scrum Guide, is a formal description of the Increment's state when it meets the quality measures required for the product, and applies to all work. Both must be met before an item counts as finished.
How many acceptance criteria should a story have?
There is no fixed number. Cohn says the team should understand what must be true for a story to be complete before it enters a sprint. Cucumber's Gherkin reference recommends 3 to 5 steps per example, and a story needing many scenarios is often too large and should be split.
Who writes user stories?
The product owner or product manager usually drafts them, but Cohn stresses that what matters is who takes part in the conversation, and that the product owner is often not the user. Developers, testers and designers contribute examples and edge cases, and the Scrum Guide has the Developers size the items.
Next step
Writing stories well takes practice on real backlogs with engineers asking questions. The Certification in Product Management with Applied AI page lists the module on working with engineering teams, which covers user stories, sprints and backlog.