How to write useful user stories: examples and acceptance criteria

“Build a dashboard” can sound clear until a developer, a tester and a stakeholder describe three different versions of it. A user story helps the team discuss who needs something, what they are trying to do and why it matters.

The useful part is the shared understanding behind the sentence. A ticket can follow the familiar format perfectly and still leave the team guessing about behaviour, scope and success.

This guide shows how to move from a vague request to a small, testable piece of work. The examples use Quest Queue, an original fictional booking tool for a tabletop gaming event. No knowledge of games is needed, and these are teaching examples rather than Coded Female services or reported client results.

What a user story should do

A user story is a brief description of a capability from the perspective of someone who benefits from it. It gives the team something concrete to discuss and confirm. Agile Alliance’s user-story guidance emphasises the conversation and knowledge behind the written card.

A common starting format is “As a [person], I want [capability], so that [benefit].” Use it to expose missing reasoning. If the benefit is simply “so that I can use the feature”, the team still needs to understand the problem.

Card: a short reminder of the need, often recorded in a shared work-tracking tool.
Conversation: discussion with people who understand the user, the product and its implementation.
Confirmation: agreed examples or checks that show whether the intended behaviour has been delivered.

These are the Three C’s, attributed to Ron Jeffries. Read the Three C’s explanation. For a distributed team, keep decisions and unresolved questions beside the story so colleagues can contribute without attending every call.

Stories are useful, but they are not mandatory for every Agile team or every type of work. The Scrum Guide describes Product Backlog items without prescribing a user-story template. A security repair, investigation or technical task can be described directly. Do not invent a user just to make every ticket begin with “As a”.

Turn a request into a story the team can discuss

1. Start with a person in a situation

Purpose: Find the problem behind the requested feature.

Quest Queue’s organiser asks for “a powerful session-management dashboard”. That could mean almost anything. Ask who needs help and when. An attendee arriving late might need to move to a later game; an organiser might need to close a cancelled session.

Those are different needs. Choose one to investigate first. For the attendee, ask how they currently change a booking, what information they need and what happens if the later session is full.

2. Write the outcome before choosing the interface

Purpose: Leave room for the team to find an appropriate solution.

Initial request: “Add a Change Session button to the dashboard.”

Useful story: “As an attendee whose travel plans have changed, I want to move my booking to an available later session, so that I can still join an activity when I arrive.”

The second version explains the situation and benefit. A button may be part of the solution, but the story does not assume a new dashboard is necessary. Sketches, technical constraints and interface decisions can be linked once discussed.

The benefit is something to investigate after release too. Delivering the button does not establish that people can successfully rearrange their plans.

3. Discuss the rules and the boundaries

Purpose: Expose decisions before they become rework.

Bring together the people who can answer product, design, development and testing questions. For the booking change, discuss:

Can an attendee move between any sessions, or only sessions on the same day?
Does the existing place remain booked until the replacement is confirmed?
What happens if another attendee takes the last place while this person is choosing?
Which bookings may this account view or change?
What happens when the change cannot be saved?

Write down agreed answers and leave unanswered questions visible. In Scrum, the Product Owner is accountable for effective Product Backlog management; the people doing the work collaborate on understanding and sizing it. A story is not a document the Product Owner must complete alone.

4. Make acceptance criteria observable

Purpose: Describe behaviour that people can actually check.

Acceptance criteria are the conditions agreed for this particular item. “The change works smoothly” is too vague. Describe what the attendee and the system should do in specific situations.

The Given, When, Then format separates starting conditions, an action and an observable result. Plain-language bullet points can work too; the format is optional.

Also check that an attendee cannot change somebody else’s booking, and that repeating a submission does not create an extra booking. Let developers and testers choose appropriate implementation and test techniques; criteria need not dictate the code.

Use INVEST to challenge the story

Bill Wake’s INVEST checklist offers six questions for reviewing a story. Use it to start discussion rather than to award a ticket a pass mark.

Independent: can this deliver useful behaviour without waiting for several unrelated features? Make real dependencies visible.
Negotiable: can the team discuss the solution while respecting agreed rules and constraints?
Valuable: does it help a user or customer achieve something that matters?
Estimable: does the team understand enough to judge the work? Investigate an important unknown before promising delivery.
Small: can the team complete and verify it within its delivery approach?
Testable: can someone distinguish the intended behaviour from a failure?

If the booking story is still too large, reduce its scope further. For example, allow moves between two named free sessions before supporting the full catalogue. Keep the permission, capacity and failure checks needed for that smaller flow.

A vertical slice is a small piece that works through the necessary parts of the product and provides usable behaviour. Separate “build the screen”, “build the service” and “build the database” tasks may help the developers organise implementation, but none alone lets an attendee move a booking. Bill Wake’s INVEST guidance discusses this distinction.

Small does not mean cutting testing or basic quality. It means choosing less behaviour to deliver properly. In Scrum, refinement helps make selected items small enough to be completed within a Sprint; it does not make every broad idea immediately ready for Sprint Planning.

Two more original examples to practise with

The game host: spot what still needs preparation

Purpose: Replace a vague dashboard request with a specific preparation decision.

Story: “As a volunteer hosting a game session, I want to see which required materials are still unconfirmed, so that I can resolve gaps before the session begins.”

For a session assigned to that host, show each required item with a text status such as “Confirmed” or “Needs checking”.
When the host confirms an item, update its status and show that the change was saved.
If saving fails, retain the previous status and explain that the confirmation was not saved.
Another host cannot edit this session unless they have been granted that responsibility.

Scope question: does “confirmed” mean someone owns the item, has packed it or has delivered it to the venue? Agree one meaning before using it to decide that a session is prepared.

After release: ask hosts whether the list helped them resolve missing materials. Counting ticked boxes alone would not answer that question.

The attendee: choose how to view the timetable

Purpose: Make the user’s information need explicit without prescribing everyone’s preferences.

Story: “As an attendee comparing overlapping sessions, I want to view the timetable as a chronological text list, so that I can compare start times and locations without using the visual grid.”

List the session title, start and end times, location and booking availability in a meaningful reading order.
Keep the chosen event day when switching between the grid and the list.
Make session links and the view-switching control operable with a keyboard.
If availability is indicated by colour, also provide a text label.

The keyboard and colour checks reflect W3C guidance on keyboard access and using colour alongside other information. These checks alone do not establish that the whole product meets an accessibility standard.

Discussion: check the proposed list with people who would use it, including screen-reader users. Accessibility belongs in the product’s normal quality expectations; this story adds a specific capability, rather than reserving access improvements for a special group.

Acceptance criteria and the Definition of Done

Acceptance criteria describe the behaviour of this item, such as keeping the original booking when a move fails. The Definition of Done describes the quality state required for the product Increment in Scrum. Meeting a story’s criteria does not replace meeting that shared standard.

For this fictional team, its quality expectations might include reviewed code, appropriate automated checks and accessibility checks. Those examples are local choices, not a complete standard prescribed by Scrum. A separate “Definition of Ready”, if used, is a team agreement rather than a required Scrum commitment.

Keep AI drafting and remote collaboration useful

If you use AI to draft stories, provide only information your organisation permits you to share with the tool. Ask it to expose missing questions and label assumptions. Do not let it invent interview findings, business value, permission rules or agreed acceptance criteria.

For example, a generated requirement that “all changes must finish within two seconds” needs a reason and an agreed way to measure it. Confident wording does not make it an approved requirement. Review the draft with the people responsible for the product and the work.

For remote or asynchronous collaboration, keep a short decision record: the question, the agreed answer, who contributed and what remains unresolved. Link a design or a technical note when it adds necessary detail. Colleagues should be able to understand the current agreement without searching several chat threads.

Try a ten-minute story repair

Choose a request such as “Add a dashboard” and name one person in one situation.
Describe what they need to achieve and why it matters. Treat unsupported details as assumptions.
Write one successful example and one failure example with observable outcomes.
Identify the smallest useful version and one question that must be answered before committing to it.

Bring that draft to a colleague and ask them to explain what the person can now do. Any disagreement gives you something useful to discuss.

Sources and further reading

Updated 15 October 2026. Quest Queue, its sessions and all example stories and criteria were created for this article. The examples illustrate discussion and testing choices; they are not a complete specification or results from a live project. INVEST is attributed to Bill Wake and the Three C’s model to Ron Jeffries.