Skip to main content

User Stories

Define​

In an Agile environment, this tool is used to describe a feature from the end user's perspective, In simple language

Writing user stories helps to gather all the requirements of a product's audience. Then, project managers can prioritize what order they should be solved, involving the production team and stakeholders. A user story contains a role or user type (the 'who'), a goal or desire (the 'what) and finally a benefit (the 'why'). They must be brief and written in plain language, so non- technical people can easily understand them. A user story is normally structured as follows:

"As a _ I want to _ so that _"

For example:

"As a registered user, I want to select my topics of interest, so that my dashboard is personalized."

Sometimes stories also include acceptance criteria. These are conditions the product must have for the story to be considered complete. So, acceptance criteria are especially useful for testing.

User stories should be very specific. If they are more generic and describe a macro functionality, they are called epics. Epics should be recorded, then broken down into more granular user stories. These would work together to 'solve' the over-arching epic. User stories are told from the user's perspective. So, designers should write them after research, as they would have built sufficient knowledge about the audience. Some teams use personas and their goals to define what stories to write.

Some of the benefits of using user stories are:

  • They are simple to understand
  • They help developers to estimate effort to build
  • They help communication between parties
  • They give an overview of the project requirements

Some of the cons are:

  • If created just by using personas, they could be based on assumptions. Job stories are an alternative tool
  • They do not address non- functional requirements
  • They can be too vague

Resources​