User Story

When a team builds an app or a website, someone first has to write down what is supposed to be built. A user story is a very short form of this description, usually just one or two sentences. It tells the story from the perspective of a person who will later use the program: Who is he, what does he want to do, and what does he get out of it? An example: “As a customer, I want to be able to track my order so that I know when the package will arrive.” What’s notable is what’s missing: not a word about how the matter will be solved technically. That is exactly the point, because the solution should be found by the developers, not by the client.

Why teams think in terms of wishes rather than features

In the past, companies wrote thick requirement specifications in which every function was defined in advance. The problem: by the time such a document was finished, the requirements had often already changed. Moreover, it stated what the program should be able to do, but not why anyone would need it in the first place. This resulted in features that were technically correct yet used by no one.

The user story turns this around. It forces the question of benefit, because otherwise the “so that” ending remains empty. Someone who cannot state a reason may not have a good one either. This way, it becomes apparent already while writing that an idea is actually superfluous.

A second advantage is size. A story is supposed to be small enough for a team to complete it within a few days. This means there is regularly something to show, instead of only intermediate states for months on end. This way of working belongs to an approach called agile development: build in short cycles, show, gather feedback, refine.

Structure, acceptance criteria, and estimation points

The most common form follows a fixed template: “As a [role], I want [goal], so that [benefit]”. The role is important because different people need different things. A teacher wants different views in a school app than a student does. If it only says “the user,” this distinction is lost.

A story usually comes with acceptance criteria. This is a short list of conditions that must be met for the task to be considered done. For package tracking, it might state: The status is visible without logging in, and if the tracking number is missing, a comprehensible message appears. Without such criteria, the team and the client will later argue about whether something is finished or not.

Before implementation, the team estimates the effort, often in so-called story points. These are not hours but comparative values: a story worth eight points is roughly twice as much effort as one worth four. After a few weeks, the team knows from experience how many points it can manage per cycle. A common mistake is to regard the story itself as a complete specification. It is more of a reminder of a conversation that still needs to take place.

From ticketing systems to AI assistants

In companies, user stories are mainly encountered in tools such as Jira, Trello, or Azure DevOps. There, each story sits on its own card, which moves from column to column: planned, in progress, tested, done. The collected open stories form the backlog, i.e., the team’s stockpile list. Anyone doing an internship at a software company is almost guaranteed to see these cards.

This way of thinking also appears outside IT. Marketing departments, government agencies, and schools now formulate projects in a similar way, because asking about the benefit helps everywhere. That’s why job postings often mention that applicants should have experience with user stories.

Recently, language models have started to play a role: teams have an AI assistant suggest drafts for stories and acceptance criteria. This saves typing work but does not replace conversations with real users. An AI can phrase something that sounds plausible. Whether anyone actually needs it is known only to those who ask.