User story

A user story describes a need, not a technical specification. "As a patient, I want to see available appointment times so that I can book without calling" says nothing about databases or buttons, which leaves the team free to find the best way to meet the need.

Stories are the basic unit of planning in agile teams. They are small enough to build in a few days, and each one should deliver something a real person would notice.

How it works

Each story has three parts: who the user is, what they want and why. It is paired with acceptance criteria, a short checklist that defines when the story is done, such as "shows the next 14 days" and "sends a confirmation email". Teams often draw the "who" from their user personas.

Stories are kept in a backlog, sorted by priority and pulled into each sprint. Large stories, sometimes called epics, are split into smaller ones until each can be built and tested on its own.

A common checklist for good stories is that each one should be independent, negotiable, valuable, estimable, small and testable, often shortened to INVEST. In practice the most useful questions are simpler: would a real person notice if this shipped, and could someone test it in a few minutes using the acceptance criteria? Stories are usually estimated with relative sizes rather than hours, for example small, medium and large, or a points scale. The team compares a new story with ones it has already built, which tends to be more reliable than guessing hours. Over a few cycles the team learns how much it typically finishes, and that figure is used to forecast how long the remaining backlog will take, with the forecast updated as stories are added or removed.

Example

For a travel agency site, the team writes: "As a family planning a summer trip, I want to filter trips by budget and month so that I only see options we can afford." Acceptance criteria: the filter offers price bands and months, results update without reloading, and an empty result shows a link to contact an agent. A developer, a designer and the owner can all read that and agree on what will be built.

During planning the developer points out that filtering by month needs each trip to have dates stored in the CMS, which they currently do not. That becomes a separate, earlier story: "As an agent, I want to enter departure dates for each trip so that customers can filter by month." Splitting it this way lets the team build and check each part on its own.

Why it matters for your business

User stories keep the conversation about customers instead of features for their own sake, which makes it easier to cut work that does not help anyone. They also let you, as a non-technical owner, review and prioritise the backlog without reading code. On a small brochure site with a handful of pages, formal stories may be unnecessary; a clear scope does the job. A quick check you can do yourself: read the backlog and see whether every story names a real type of customer or staff member. Stories that name only the system are usually technical tasks in disguise.

Common mistakes

• Writing the "so that" part as a restatement of the goal, which hides the real reason and makes prioritising harder.
• Using "as a user" for every story instead of naming a specific type of person.
• Skipping acceptance criteria, so nobody can say for certain when the story is finished.
• Writing stories so large they take weeks, instead of splitting them into pieces that can ship separately.

Questions people ask

What is the format of a user story?

The common template is "As a [type of user], I want [goal] so that [reason]." It is followed by acceptance criteria that list the conditions for the story to count as done. The template is a guide, not a rule; clarity matters more than the exact wording.

Who writes user stories?

Usually a product owner or project manager, often with input from the client, designers and developers. In small projects the agency may draft them after discovery and ask the client to review and prioritise them.

What is the difference between a user story and a requirement?

A traditional requirement often states what the system must do in technical terms. A user story states what a person needs and why, leaving the solution open. Acceptance criteria then add the specific, testable conditions.