Writing User Stories — A Minimalist’s Approach
This article serves as a light-weight approach for preparing & writing user stories. If you are just starting your own product or lost in the middle of vague product requirements, here’s what you can use to start moving fast; and trust me, don’t look any further, what’s provided in this article is just what you need.
Step #1. Define the Personas
Personas are the types of users using the system. For an e-commerce system, these user types might be:
- The Customer. The signed-up site visitor that buys products.
- The Seller. The signed-up site visitor that adds product to his e-commerce shop.
- Anonymous Visitor. The site visitor that is not registered yet.
- The Admin. The administrator that handles administrative tasks on the site.
- The Support. The site support that can respond to customers or sellers.
Quick Note: Personas could resemble User Roles, but do not resemble permissions on the system. A Persona can be assigned permissions, for example, a Support User might be granted permissions to delete users or denied deleting users. You can blend the two concepts by having User roles of Normal Support User and Administrative Support User where the latter contains elevated Support permissions. Just keep this in mind when defining Personas and evaluating the permissions on the system.
Step #2. Define the User Stories
A User Story is a description of an action a user can perform in the application and benefit from. When using Jira, usually each User Story has a corresponding Jira Ticket.
Guideline #1: Write a user story using the following template format
As a <type of user>, I want to/I can/I’d like <do something>, [so that I <get some benefit>].
The sub-phrase between square brackets is Optional.
As a registered user, I can use my username or email address with the password to log into the application.
As a Seller, I want to be able to add a product, so that I can offer it to customers to be sold.
As a Seller, I want to be able to hide a product, so that I can hide it from my shop and stop selling it.
Guidelines when writing user stories:
Guideline #2. Make sure it covers an end-to-end interaction. DO NOT write a user story for filling in a registration form, and another user story for receiving a confirmation email to verify the registration. These two should be the same user story.
Guideline #3. Keep User Stories Small. DO NOT write a user story that is very broad. A very broad user story is better suited as an Epic.
As a Seller, I want to manage products. <<< WRONG, VERY BROAD
As a Seller, I want to be able to add a product and specify the name, price, initial quantity and multilingual names.
As a Seller, I want to be able to delete a product.
As a Seller, I want to be able to update the products price while tracking the history of the previous prices.
Guideline #4. Add Acceptance Criteria to User Stories
For each user story, there should be an acceptance criteria, for example.
The acceptance criteria for a user registration user story could be:
- The email address must not already exist in the system
- The username must not already exist in the system
- The password must be at least six character, contain at least one number and one special character.
Note: Sometimes I add Preconditions Criteria too. For example, a user story might require a Precondition that a Support User have permission to delete a seller. You can include these Preconditions with your acceptance criteria at the top.
Guideline #5. Avoid mentioning UI elements in user stories.
BAD USER STORY:
As an administrator, I want to click the Search Button after entering part of the username in the Search Text Field.
GOOD USER STORY:
As an administrator, I want to be able to search for users by username, email address and registration date.
Guideline #6. Group User Stories by Epics
For example, for user stories related to User management, you can create an Epic called “User Management Epic” and list all User Stories underneath that Epic.
Epic User Management Module contains the following user stories:
- As an Administrator, I need to add a Support User
- As an Administrator, I need to delete a Support User
- As an Administrator, I need to lock & unlock a Support User account.
- As a Seller, I need to have forgot password functionality, in case I forgot my password.
Step #3. Preparing the Wireframes
After writing User Stories, you can in parallel, or after finishing of all user stories or an Epic, start drawing wireframes by sketching on paper, or a white board or using a wireframe online tool.
A wireframe tool might be the best since you can link the wireframe back to your user story.
- Chapter 4 — Managing requirements in an Agile way
Building Applications With Spring 5 and Vue.js 2 — James J. Ye