User Story is a brief description of a new Product functionality or its enhancement. It does not contain a technical solution but addresses questions concerning the functionality: Who is the user? What does the Product do? And What is its purpose? The User Story describes the product in everyday or business language, though it also points to Scrum Team’s tasks that are intended to improve the Team’s performance.

What are User Stories? – table of contents:

  1. Introduction
  2. User Story. Whose story is it?
  3. How to use User Stories?
  4. Acceptance Criteria
  5. Summary


User Story is the most common way of formulating the tasks performed by the Scrum Team. A single User Story defines a small functionality of the Product. It describes the smallest meaningful, partial Product Goal. For this reason, User Stories are very brief.

User Stories are created throughout the entire time of working on the Product. They are created continuously, from the moment the decision to start work is made, to the realization of the Product Goal.

Creating User Stories is a Product Owner’s task. Based on a conversation with a Customer, formulates answers to questions that allow to create User Story and enters them into the Product Backlog. However, User Stories reflect not only customer needs.

user stories

User Story. Whose story is it?

The Scrum Team creates a User Story to define the User’s needs, and that’s why it is put down in business language. In other words, it indicates the benefits that its implementation will bring to the product user. However, in the Product Backlog, there can also be User Stories that describe the needs of the Development Team, for example improving the workflow between Developers, or describing the needs of the Product Owner, for example organizing the Product Backlog. In such cases, the User in the User Story is the Developer and the Product Owner.

You can describe a User Story by answering the 3W questions:

  • Who?
  • Is doing What?
  • Why?

The User Story is then contained in a formula:

As a [user type], I want [to do what?] Because [why? why?].

Examples of User Stories about the functionality of an online store written in this form are illustrated in the table below:

What are User Stories? - table

This formula allows not only to formulate a User Story but also to relatively easily translate technical language into business and vice versa. As a result, both Developers and Stakeholders see clearly the Goal and stages of its progress. We will also cover creating good User Stories using the INVEST method in a separate article in the Scrum Guide series.

How to use User Stories?

Creating a schematic User Story is just the beginning. They are signals and starting points for discussions on problems and their solutions. Discussing User Stories takes place during Sprint Planning to sort out which technical issues the Development team will add to the Sprint Backlog.

Typically, in the physical space, User Stories are written on small, colored cardspinned in the workplace. However, in the digital space, digital whiteboards, shared by the Scrum Team, work best.

Saving User Stories in this way has several advantages because:

  • Stresses the autonomy of each User Story – each has a separate framework and can be executed independently of the others
  • Emphasizes the dynamics of User Stories – the order of their realization is renegotiated by the Scrum Team and the current order of realization is visible on the board thanks to the physical arrangement of cards with User Stories
  • Serves as a reminder – thanks to the visual representation of User Stories, the Scrum Team has a signpost in sight to remind them of the goal when creating detailed solutions.

The Development Team estimates the required effort to complete a User Story with days, man-hours, or Story Points.

Acceptance Criteria

A User Story must have certain acceptance criteria at the very moment it is accepted for development by the Development Team. The acceptance criteria determine at what point work on a User Story can be considered finished.

This way both the client and the developers know how their work will translate into business value. Typically, a User Story is considered completed when the user-specified in it can perform the action described. Using the example above, take a look at this User Story with the content:

A customer can buy a magic wand with a single click.

It is completed when a working ”Buy Now” button appears on the online store page, which uses the default payment and shipping information for the logged-in user.


A User Story is a concise description of a new Product functionality or enhancement. It serves as the smallest Goal expressed in business language, that is, from the perspective of the business value and the user. It helps to clearly define the task to be performed as well as the criteria for its completion.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 19. User Stories - what they are? caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing