User stories are simple statements that are used to describe pieces of functionality from a user’s point of view. They are used to represent what the user needs.
A user story is written in a simple and understandable way and they are a great way of clearly describing the solution’s functionalities. Well written user stories are used to focus on the stakeholders needs.
User stories should be easy to describe, understand, amend and explain. They are used to break down the solution into small achievable testable pieces of work and are the smallest pieces of work that is used to implement the solution.
It might seem easy to write a good user story given their simplicity but there are a few guidelines that should be followed when writing a good user story.
- Define the expected result: The user story is considered “done” when the stated task is completed. But in order to complete the task, the expected result has to be clearly defined so that the user knows the expected results.
- Create sub tasks: If numerous steps have to be taken to fulfill the user story, then each of those steps should be created as subtasks in the user story.
- Create user personas: If there are numerous end users in the user story, then you should create multiple stories for each end user instead of merging them all into a single user story.
- A user story per step: a user story should be created for each step in a process, you should not merge all the steps in a process into a single user story.
A user story usually has the following structure
“As a [user persona], I [want to], [so that].”
But what does this mean?
User persona: this is the actor whose wants to accomplish something.
Want to: this is what the actor wants to accomplish.
So that: this is the why the actor wants to accomplish the thigh.
An example of a good user story is:
As a bank employee, I want to create a new customer account, so that the customer can perform their banking transactions.
Every user story should have clear acceptance criteria. Acceptance criterion is a set of conditions that are used to confirm when a user story is completed.
User story example: As a transit supervisor, I want to know the number of available drivers in the pool so that I can plan the bus schedules for the following week.
The acceptance criteria for this user story would be: The application should show the list of available drivers for the following week.
What are Epics: Epics are statements that are used to group a set of related user stories.
But how are Epics and user stories related?
An Epic: A user should be able to create and update their user profiles.
A related user story: As an application end user, I want to be able to create a new user account so that I can access the software application.
A related user story: As an application end user, I want to add profile photos to my user account so that people would be able to identify me.
A user story: As a business analyst, I want to limit the user’s profile picture size so that they don’t upload files bigger than 2 megabyte.
A user story: As an application end user, I want to have a field where I input a brief description of myself so that people can get to know me.
So, Epics are used to provide a summary of our goals and the user stories would break that epic into small, testable, achievable pieces of work.
To create a user story, you should ideally start with an epic and then break the epic into smaller, achievable chunks which become the user stories.
Good user stories should fulfill the INVEST criteria, which is:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
The user stories should be created from the user’s point of view, so if you are in doubt liaise with the user and then use their feedback to help create the user stories.