User stories: how to write one, with examples

A user story starts with a person

A user story is a short description of a result someone needs. It helps you discuss who needs the work and why before choosing its technical implementation.

“Add a button” sounds specific, but does not explain the problem it solves. You can build the button exactly as designed and still fail to help anyone. A user story starts with a situation: someone is choosing a workshop and wants to make sure they can arrive before it starts. Only then does the team decide whether a schedule is enough or a time-selection feature is needed.

Below is an illustrative example of a workshop website. It is neither a description of Sinqly features nor a client case study. We will move from a vague request to a small story that can be discussed, checked and put into work.

The format: role, need, benefit

A common template is “As a [role], I want [a capability], so that [a useful result].” It supports a conversation rather than imposing mandatory grammar. If the sentence sounds unnatural, rewrite it in plain language while preserving those three meanings.

The role is not a generic “user”, but a visitor choosing a class. The capability is seeing the available options. The benefit is finding a suitable time. “So that” checks the causal link: “so that viewing is possible” merely repeats the first half and explains nothing.

You do not need dozens of roles. If first-time and returning visitors need the same result under the same conditions, one story may cover both. A separate role helps when the actions, constraints or required result differ: an organiser manages capacity, for example, while a visitor chooses a place.

Three formulations worth improving

Do not force technical tasks into user stories. Updating a library or configuring backups is valid work with its own justification and checks. An invented role such as “as a server” usually obscures what needs to be done.

If the story already specifies a colour, field position and storage technology, check whether these are genuine constraints. Sometimes the existing system or accessibility requirements justify them. Record them separately rather than mixing them with the reason someone uses the product.

Add boundaries and acceptance criteria

One sentence does not replace an agreement about behaviour. For our story, the team records separately that only the selected day's sessions are shown, full sessions cannot be booked, choosing another day refreshes the list, and a clear message appears when no places remain. Payment, cancellation and rescheduling are outside this story for now.

1. A day has two available sessions: the visitor sees both times and can choose one.
2. A day is fully booked: no session can be selected, and the lack of places is shown.
3. After choosing a day, the visitor changes the date: the old selection is cleared, and the new date's options become available.
4. Another visitor takes the place before confirmation: the system explains the change and does not promise a place that no longer exists.

The last condition reveals an important boundary case. Discovering it only at release can lead to “we never asked for that”. Discussing it beforehand lets the team estimate the complexity separately and decide whether protection against simultaneous bookings belongs in the next result.

More about acceptance criteria, with success and failure scenarios to check.

How to split a large story

“I want to manage all classes” includes many different actions. Look for a complete path that already gives someone a useful result. A small first release might let them choose one session and confirm a booking; rescheduling and a waiting list can become later stories.

“First the whole database, then the whole server, then the whole interface” describes implementation stages. That may belong in a technical plan, but it does not create three independently useful user stories. Such technical tasks can sit within the first story; keep the two levels distinct.

Do not split work just to create more cards. If two parts cannot meaningfully be shown and checked separately, the boundary is probably unhelpful. If the story still hides an unfamiliar integration, first record the question and a short investigation.

A conversation before starting the work

The story's author, the person doing the work and the person checking the result can walk through one ordinary scenario and one awkward one together. In our example, these are a Saturday with available places and a session whose last place has just been taken. Ask each person to describe the expected outcome in their own words: differences emerge sooner than they do when everyone silently approves a document.

Suppose the developer understood an “unavailable session” as hidden, while the administrator wanted it visible in grey to explain the schedule. Both read the same phrase but imagined different things. Record the decision and reason beside the story. Do not leave them in a call recording the next participant may never open.

Where to keep the working result

In Sinqly, you can create a task called “Clarify workshop booking” and add the story, four check scenarios and explicit exclusions to its description. Signing up is free.

DesktopMobile

View screenshot ↗

Close ×

A real Sinqly task card from the screenshot library, showing the description field in a different illustrative example. The screenshot uses Russian demo data. You enter the article's content manually; it does not show a dedicated specialist module.

How to apply the template to your own task

Take one real request from a work conversation. First, write it down verbatim. Then answer separately: who encountered a difficulty, what are they trying to do, and how will they know they succeeded? Only then write the story. This reduces the risk of neatly documenting a feature that has already been chosen but is unnecessary.

Keep the original request beside the new formulation to help explain why the solution changed. After a demonstration, ask both “does it meet the list?” and “did it produce the result we needed?” Passing requirements checks does not prove that the original hypothesis about the need was correct.