A user story is the documentation that represents the smallest increment of work a development team does. User stories are often referred to in two different contexts:
- As overall tickets
- As a written, first-person value-statement from the perspective of a user
Tickets can contribute to an epic or they can be a single, standalone ticket. An epic is typically a collection of user stories accomplishing a larger initiative.
User stories consist of four main categories:
- Title (short description of ticket)
- User story description
- Acceptance criteria
- Story point estimation
The term story is used to depict that the user is on a journey. The task is aiding the user on their journey. User stories are written from the perspective of the end user. This has the following benefits:
- Helps whoever is writing the ticket to think customer-first and consider the desired outcome that a user wants
- Helps developers to understand the context behind what they’re building
- Helps QA to get into the mindset of the user while testing
The format of a user story is typically written as:
As a <user persona>
I want <an action>
So that <describe benefit>
Example
As a student
I want to be notified when my assignment is coming due
So that I can complete it on time
Acceptance criteria
After the context of the ticket is written in the form of a user story, the details of the ticket are outlined in the form of acceptance criteria. The criteria are the detailed requirements that must be met in order for the ticket to be accepted and complete. This criteria is listed numerically and includes designs (when applicable).
The format of acceptance criteria is often written as:
Given <condition>
When <action>
Then <outcome>
Example
Given my “New Assignment Notification” setting is set to true
When a new assignment is available for me
Then I should receive an email with a link to the assignment
Story point estimation
After user stories are written, they go to the Scrum team for review and estimation. After discussing the contents of the user story the team estimates the size of the ticket. This is often done in the form of Fibonacci story points. Understanding the sizes of each user story helps the team to predict with some relative reliability when those stories can be completed.
Related quotes
Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process — which is the most critical part of software development itself.