User Stories and Product Backlogs: A Practical Guide
How to write useful user stories, add clear acceptance criteria, check them against INVEST, refine a product backlog and split large stories into valuable slices.
The Agile Coach · Last reviewed October 21, 2026 · 5 min read
A product backlog is the list of things a team might build, and user stories are one of the most popular ways of writing the items on it. Done well, stories keep a team focused on the people it serves and invite the right conversations. Done badly, they become a rigid template filled in by rote, and the conversations never happen.
Neither user stories nor any particular story format is required by Scrum or Kanban. The Scrum Guide simply describes Product Backlog items and leaves their form to the team. Stories became popular because they work well for many teams, especially when they are treated as a starting point for discussion rather than a complete specification.
This guide covers the common story format, acceptance criteria, the INVEST checklist, backlog refinement and techniques for splitting stories that are too big.
What a User Story Is
A user story is a short description of something a user wants, written from that user's point of view. In 2001, Ron Jeffries described three critical aspects of stories in Extreme Programming, often called the three Cs:
- Card: the story is written on a card, with just enough text to identify the requirement, not the whole requirement.
- Conversation: the details are worked out through conversation between the people who need the feature and the people building it.
- Confirmation: acceptance tests confirm that the story has been implemented as understood.
The card is the smallest part. The conversation and the confirmation are where the shared understanding is built.
The Common Story Format
Many teams write stories using a three-part template: "As a [type of user], I want [some goal] so that [some reason]." Mike Cohn of Mountain Goat Software credits this template to agile coach Rachel Davies at a UK company, Connextra, in the early 2000s.
For example: "As a returning customer, I want to reorder a previous purchase so that I can restock quickly." The template prompts the writer to think about who benefits and why, which helps the team make sensible trade-offs later.
The format is a tool, not a rule. If filling it in produces awkward sentences like "As a system, I want a database," that is a sign the item is a technical task rather than a user-facing story, and it may be better described plainly.
Acceptance Criteria
Acceptance criteria describe the conditions a story must meet to be accepted. They are the confirmation part of the three Cs, and they turn a vague story into something testable. Good criteria describe observable behavior, not implementation details.
For the reorder story above, criteria might include:
- The customer can see a list of previous orders from their account page.
- Selecting reorder adds all available items from that order to the cart.
- Items that are no longer available are listed with a clear message and are not added.
Some teams write criteria as example scenarios in a Given/When/Then style, such as: given a customer with a past order, when they select reorder, then the available items appear in their cart. Either way, criteria should be agreed before work starts. Acceptance criteria apply to a single story; they are different from a team's Definition of Done, which applies to every item.
Checking Stories with INVEST
Bill Wake introduced the INVEST acronym in a 2003 article as a checklist for good stories. Each letter names a quality:
- Independent: stories ideally do not overlap and can be scheduled and built in any order.
- Negotiable: a story is not a contract for features; details are worked out together during development.
- Valuable: it delivers value to the customer.
- Estimable: the team understands it well enough to give a rough estimate that helps with ranking and scheduling.
- Small: Wake wrote that stories typically represent at most a few person-weeks of work, and some teams keep them to a few person-days.
- Testable: whoever writes it understands the need well enough that a test could be written for it.
INVEST is a set of questions, not a pass-or-fail exam. A story that is not quite independent may still be fine. The value is in noticing when a story fails several checks at once, which usually means it needs more conversation or splitting.
Backlog Refinement
The Scrum Guide describes Product Backlog refinement as breaking down and further defining backlog items into smaller, more precise items, adding details such as a description, order and size. It is an ongoing activity, not a formal event. The Developers who will do the work are responsible for sizing, while the Product Owner is accountable for the backlog's content and order.
Practical refinement habits include:
- Refining a little and often, so items near the top of the backlog are always ready to discuss.
- Involving the people who will build and test the work, not only the Product Owner.
- Keeping detail proportional to priority; items far down the list can stay rough.
- Removing items that no longer matter, so the backlog stays honest and manageable.
A backlog of several hundred items is usually a sign that it has become a wish list. A shorter, ordered backlog is easier to understand and change.
Splitting Stories
Large stories are harder to estimate, slower to deliver and riskier. Splitting them is one of the most useful skills a team can build. The goal is vertical slices: each smaller story should still deliver some visible value to a user, rather than one slice for the database, one for the interface and so on.
Richard Lawrence and Peter Green of Humanizing Work describe several splitting patterns, including:
- Workflow steps: deliver the simplest path through a process first, then add steps.
- Operations: split create, read, update and delete into separate stories.
- Business rule variations: handle one rule first, then others.
- Variations in data: support one type of data first, then more.
- Simple versus complex: deliver the simple core, then the complications.
- Defer performance: make it work first, then make it fast.
Imagine a team asked to build "checkout with all payment methods." Split by data variation, the first story might support credit cards only, with digital wallets and gift cards as follow-up stories. Users get a working checkout sooner, and the team learns from real usage before building the rest.
Key takeaways
- User stories are optional but popular; the conversation and confirmation matter more than the card.
- The As a, I want, so that template is commonly credited to Rachel Davies at Connextra and is a prompt, not a rule.
- Acceptance criteria make a story testable; the Definition of Done applies to all work.
- INVEST, introduced by Bill Wake in 2003, is a helpful checklist for story quality.
- Refine continuously and split large stories into thin vertical slices that each deliver value.
Sources
Spotted something out of date? Let us know.