What are User Stories?

User Stories are brief descriptions of a product feature from the point of view of the user. They usually follow a basic template.

As a < user >, I want to < achieve goal > so that < reason >.

Many user stories are written on sticky notes or index cards. They are often placed on tables or walls to facilitate planning and discussion. They help shift the focus away from writing about features and towards discussing them. These discussions are far more important than any text written.

Examples user stories

Agile user stories have the advantage of being able to be written at different levels of detail. Also known as epics, user stories can cover large quantities of functionality. Here is an example of an epic agile user story from one of our clients:

As a user, I want the ability to cancel my order so that I can correct mistakes.

An epic is usually too big for an agile team to complete in a single iteration. Therefore, it is divided into smaller user stories before being worked on. You could split the epic into many (or even hundreds) of stories, including these three.

As a user I want to select the order from my list of orders so that I can cancel any open order.

As a user I want to see details of order so that I cancel the right order.

As a user I want to get a confirmation of the cancellation of the order so that I know the order has been cancelled.

What is the purpose of adding detail to user stories?

Basically, there are two ways to add details to user stories:

1. Splitting a user story into smaller stories allows you to make it more manageable.
2. You can add "conditions for satisfaction."

It is reasonable to assume that more detail has been added when a large story is broken into smaller user stories. There is simply more to tell. Conditions of satisfaction are a high-level acceptance checks that will apply after the agile user story has been completed. Here's an example:

As person responsible for marketing, I want to review past advertising campaigns so that I can identify most effective campaigns.

For example, you could add detail to the user story by including additional conditions of satisfaction:

1. Selection of different customer segments (new customers, existing customers)
2. Campaign outlets (e.g., social media, native ads, etc.)
3. Campaign audience

Who creates user stories?

Anybody can create user stories. Although it is the responsibility of the product owner to ensure that there is a product backlog with agile user stories, that does not mean that they are the only ones who write them. Each member of the team should be able to write user story examples over the course of an agile project. It is also important to note that the author of a user story is less important than those who participate in the discussion.

What are the best times to write user stories?

Throughout project user stories can be created. However, to get everbody on board, it makes sense to have a workshop on story writing at the beginning of the project. Since every member of the team takes part in creating the product backlog, all perspectives on the product are considered. You can also have specific points during the project to add user stories to the backlog.

Sme of the user stories will be, undoubtedly, epics. These will be broken down into smaller stories that can fit into one iteration. You can also add new stories to the product backlog at anytime and by anyone.

Do user stories replace a requirements document?

Agile projects use a product backlog, which is a prioritized listing of functionality that will be developed for a product or service. While product backlog items can be virtually anything, user stories have been the most popular and effective items product backlogs.

Although a product backlog can be seen as substitute for the requirements document for a traditional project, it's important to remember that the written portion of an agile user story ("As user, I want ...")") is not complete until there are discussions about the story.

It makes sense to consider user stories as a guide to the actual requirement. A user story could point to a flow diagram, a spreadsheet that demonstrates how to do a calculation, and any other artifacts the product owner or team would like.