A User Story is an Agile practice, primarily used in Scrum in order to capture the users’ needs by expressing the characteristics, functions, and requirements of the product to be created, in a general and not overly detailed way. 

User stories are part of the Product Backlog, which in Scrum represents a list of all the tasks that need to be accomplished in the project. They are simple, but really effective since they allow you to focus on the needs and requirements of the user and/or customer, as well as the value to be achieved.

User stories are often written on paper or post-it notes and are hung on the wall or on a whiteboard to facilitate their discussion and planning. Thus, the project team spends more time discussing functionalities instead of writing them. As a result, they comply with one of the Agile Manifesto’s 4 values, which fosters “the operational software rather than exhaustive documentation”.

What are User Stories used for?

User Stories are an excellent tool for clearly defining the product/service features. A hierarchical well-written set of user stories can certainly help the team express and identify product functionalities without going into technical details.

A User Story allows team members to understand the importance and impact of each feature on the business, as well as helping the customer understand these features’ usefulness and priority.

When properly written, user stories provide a solid base for communication and collaboration, by putting the user in the center of attention. User Stories facilitate discussions about the product, both within the development team and with external stakeholders.

How is a User Story structured?

Each user story describes one of the product features that need to be done, for whom it should be created, and for what reason, all in a simple and comprehensible way for both the customer and the developer. The quantity of information that each user story contains is essential to allow the development team to make an approximate estimation of the amount of work required to complete it.  

Even though there are different ways to write a user story, they all have a purpose, a brief description, as well as acceptance standards and conditions under which the user story can be considered done. This is the typical structure of a User story:

As <type of user>, I want <the goal> in order to <the reason>

Here are two examples:

• As a customer, I want to cancel my hotel reservation in order to get a refund.
• As a customer, I want to be able to connect in order to securely access my account.

Discussing user stories with the customer and/or user is really important; it is only through dialogue that the project team can understand and cover all the different aspects of a user story. Hence, the project team can have a good understanding of “what” and “why” a specific functionality should be developed.

What are the main characteristics of a user story?

Typically, User stories must have 6 main characteristics, which are represented by the acronym INVEST:

• Independent: they must be separated from each other.
• Negotiable: they must be negotiable and open to any contribution from all concerned parties.
• Valuable: they must bring added value to the customer.
• Estimable: they should be estimable, not precisely, but at least roughly in order to allow planning of their implementation.
• Small: they must be small, in order for the team to be able to realize the functionality in a maximum of a few working weeks and for estimates to be more precise. If the user story is too complex, it is preferable to break it down into several small User stories.
• Testable: they must be apt to testing by including information on how to perform tests on them.

Who writes user stories?

User stories can be written by anyone who has the required skills to accomplish the task. However, it is the product owner’s responsibility to make sure a product backlog of agile user stories is properly and accurately created. Over the course of an agile project, you can have user stories written by different team members. Keep in mind that who writes a user story is far less important than who participates in the discussions about it.

The team will always have valuable input for the product owner to add to the user stories. The authority of selecting which user stories get executed should rest with the product owner, but as far as writing the actual stories, this should be a shared responsibility amongst the entire team.