What is a User Story?

User story. Explain functionality from the viewpoint of the user.

Which advantages do user stories have and what do you have to pay attention to when creating them?

tooltip text

With a user story, you can describe the features of the system from the view of the user. It serves as a basis for finding requirements.


A user story is formulated in one to two sentences and always has a particular structure that calls out the who, what and why. It also lets the additional acceptance criteria be listed.

What is a user story?

A user story tells a short story from the viewpoint of the user to describe a system’s desired functionality. For this purpose, you just concentrate on the what and write your story in simple language so that all participants can understand, even those without a technical background. Because the user stories should form a bridge between development and customers. How exactly to implement the functionality is irrelevant for a user story. A user story is also flexible and adapts to new findings: It can be recorded roughly and filled with more details until it is detailed enough to be implemented. The goal of a user story is always to create added value for the customer.

Definition of a user story:

A user story is a tool in agile project management to describe system features from the point of view of the user. It serves as a basis for finding requirements.

Use case vs. user story

If you work agilely, then you also use use cases often: You describe how actors interact with the system under development. Use cases are very popular because they create a foundation, like user stories, of finding requirements for products. Additionally, it is their goal to create added value for the user or the stakeholders. So what is the difference between use cases and user stories? Use cases are very extensive, because they offer information on an entire context. They are long-lasting and are maintained over the entire project, whereas user stories normally only last one iteration. Is one more recommended than another, or do they cancel each other out? The answer is: no, use cases and user stories just create different perspectives of the system and complement each other well. That is why it is worthwhile to use both tools together in your project. For example, user stories are recommended to understand and map scenarios. Through the combination of both methods, you can define your requirements more easily and precisely. To use user stories as planning instruments, they can be cut into smaller use case slices. This procedure evolved from the use case 2.0 approach.

Click here to read more about use case 2.0 »

Features of a user story

  • Goal: create added value
  • Short, small and compact
  • Lightweight
  • Compares the scenarios of a use case
  • Short lifespan, only lasts the iteration

Features of a use case

  • Goal: create added value
  • Detailed, large, covers context
  • Extensive
  • Collects multiple user stories
  • Long-lasting, continues for the entire duration of product development

Good to know:

The user story originated in extreme programming (XP). Since then, user stories have become a popular aid in other agile methods like Scrum.

How to write a user story in practice

Learn more about agility here with objectiF RPM »

objectiF RPM

How to write a user story

To be able to write your user stories, you need information. This can be found, for example, in conversation, through user observation or through surveys. And then you formulate the content of the user stories.

This content consists of one or two sentences and always has a specific structure. Traditionally agile projects work with index cards, like for example Scrum projects, upon which you describe the feature. To simplify the planning and creation, you often use a software that offers textual templates for user stories.

Templates and examples

To describe a user story, use the following template:

As (role) I would like (feature) to achieve (benefit).

Through this structure, the user story clarifies the important questions of who, what and why. For this formula, you always have to make sure that it is written from the point of view of the customer and that it really generates a benefit for them. For example:

  • As a bank machine user I would like to withdraw cash so as to be able to pay with cash.
  • As a bank machine users I would like to be able to view my bank account balance to be able to decide how much I want to withdraw.
    You might have noticed how broad the first user story is, whereas the last one is more specific. That is normal because you often work from larger problems to smaller ones.

User stories can differ, then, in their scope. To consider this scope, classifications have arisen: features, epics and user stories.

Feature, epic, user story

The difference between features, epics and user stories is not standardized. Each organization or each project can decide whether and how user stories are classified. For example, there is the following division:

Features: Describes the features on the highest expert level.

Epics: Refines the functionality of features, but they are still too broad to be implemented in an iteration, plannable for releases.

User Story: Refines epics and lets them be planned for sprints, so that they can be implemented in a few days or weeks.

To dismantle features and epics into small user stories, refine the larger user stories according to specific principles. For example:

  • according to workflows
  • according to workload (high vs. low)
  • according to complexity
  • according to spike stories

But how to you determine exactly whether you have defined a suitable feature, epic or user story? Is it enough to think it suits? To decide on an objective criteria, use the invest principle by Bill Wake.

User stories and the INVEST principle

Independent A user story can stand for itself without being dependent on other user stories.
Negotiable At the beginning, the user story includes only a few details, and little-by-little becomes more detailed as it is discussed.
Valuable User stories bring customers/users added value.
Estimable The workload of a user story can be estimated by developers.
Small User stories have to be implementable within an iteration.
Testable User stories must be testable.

What is the acceptance criteria of a user story?

The implementation of a user story has to be testable. But how do you know if this has been completely implemented? The answer to this is: you define acceptance criteria for the user story – so key data points that your user story has to deliver.

With this criteria the product owner can remove the user stories later in that they just tick off the points on a checklist. The acceptance criteria develops from the coarse notes to an extensive acceptance test that allows the user stories to be checked with test cases.

How can you estimate the workload of a user story?

To estimate the workload of a user story, two methods are recommended: story point and person days. Story points are gladly implemented into agile projects and consist of simple numbers, for example, Fibonacci numbers (1, 2, 3, 5, 8, etc). The higher the workload of a user story, the larger the number. That way an estimation of relative values emerges: a user story with the workload 2 is, for example, more quickly finished than one with 8.

In many projects, you work both agile and classically, that means that you calculate in both hours or person-days so that you can determine the duration and costs of your activities. To implement this hybrid project management, you should use the classical workload estimation with person-days for user stories.

Click here to learn more about hybrid project management »

Technical stories and spike stories

Apart from user stories, development teams also often use technical stories. These stories don’t describe functionality, but rather criteria that clarify the technical effort behind a user story. Similar to misuse cases, technical stories also try to determine non-functional requirements like security, performance or scalability. If you also want to implement technical stories, you have to pay attention to the clear separation of user stories and technical stories – for example through an identifier. That way you avoid misunderstandings with prioritization.

If information or identifiers for a user story are lacking, you can create spike stories: you formulate a question to be answered or an enquiry that has to be carried out. That way you can make a user story plannable and estimatable. For example, the template for a spike story is :

In order to (reach goal), (system or role) has to do (action)

Download Whitepaper User Stories - Backlogs - Backlog Grooming

Knowledge to go

Everything about User Storys, Backlogs and Backlog Grooming

Whitepaper for download »

More Downloads

  • Whitepaper
  • Tips & Tricks
  • Software

Downloadcenter »

The advantages of user stories, summarized


User Storys …

making the goals and desires of the stakeholders clearer for the developers

supporting iterative development

quick to create

having a short and understandable structure and language

simplify estimation of the workload

degree of detail can vary (feature, epic, user story)

To the features with user stories

User stories lead developers and stakeholders together because they describe features of the system simply. They are formulated shortly, can be created quickly and complement development with use cases. But how do you handle a large number of user stories without losing the overview? How can you estimate the workloads and plan the stories for the next sprint? How can you refine features and epics and ensure the traceability and testability of the user story at any time? And what happens if you have to maintain changes or if you want to work with technical and spike stories? With software you can use a template to create user stories quickly, estimate their workloads and allocate them to sprints or backlogs. If you want to create features, epics, technical stories or spike stories, then this can be identified precisely and refined into user stories if necessary – always traceably and comprehensible for every project participant. And even test cases can be connected with user stories in a few clicks so that the implementation of the features can be checked.