When developing mobile apps, you need to clearly define who the users are and what they can do with your app.
Without user stories, it can take a lot of documentation for every stakeholder to truly understand the product’s functionality and value from the user point of view.
SO WHAT ARE USER STORIES?
User stories make it easy to write software (mobile app) requirements from the user’s perspective rather than the functionality. Please note that a user can be a shopper (e-commerce app), a passenger ( ride-hailing app), or an Admin (platform owners).
WHY USER STORIES?
Writing user stories are a better way of documenting user requirements because;
1. They are easy to understand
2. Make it easy to know what to prioritize
3. Includes the business value
Without really understanding the business need, it is easy to get carried away with nice to have features like realtime messaging. Let’s say you want to integrate a chat functionality to enable users to contact support directly from a mobile app;
We can look at it from 2 different approaches;
1. The ‘Generic User Requirement’ approach
“Users should be able to chat directly with support.”
I can argue that a user requirement written this way, can make 80% of mobile app development teams to implement a realtime chat feature, which is good.
2. The User Story approach
“As a user, I want to chat directly with support, so that I can occasionally report my concerns.”
The above format (which is a better approach) makes it clear to stakeholders and development teams that a realtime chat between user and the support team will be an overkill. Because reporting a concern or bug does not happen as frequently or need the same urgency when compared to chatting with another user. So the chat feature can be quickly implemented in a non-realtime manner, thereby saving you a lot of money and time if you are building an MVP.
A typical user story can be broken down into three parts. The type of user, what the user needs to do, and the business value the user gets.
As a <typer of user>, I want to <do something>, so I can <achieve some goal or value>.
What makes up a good user story?
According to Bill Wake, a good user story should be Independent, Negotiable, Valuable, Estimable, Small and Testable.
- Independent: A good user story should be able to pass a complete message. It makes the story easier to work with.
- Negotiable: A user story cannot be final, nor seen as a contract in itself, but can be redefined, and modified as the development process continues. A good user story should be able to be broken down into smaller user stories even after it is being written down.
- Valuable: A good user story must be relevant to your customers/users and the business. It is best to Include the functionality and the value in the user story.
- Estimable: This helps to place a priority on the user stories. The value and the development time should be estimated; it might not be an exact estimate but enough to help in ranking.
- Small: A user story should be written in simple language, and written in one to three lines. The aim is short and concise.
- Testable: A good user story is an easily testable story. We cannot develop what we cannot test. A non-testable user story is: “software should be easy and pleasant to use”
HOW TO WRITE YOUR OWN USER STORIES
1. Start with the user’s need or value.
As I emphasized earlier, the primary importance of a user story is that it is not complete without including the business need. You can start with the problem your intended users are currently facing, then define the way your app will help them overcome these issues.
2. Create EPICS (Big user stories)
An epic is a high-level user story that helps you define your app functionality without going into the details.
Here’s an example:
You are creating a music streaming app; you want users to be able to different to selected plans to listen to music
EPIC:
User subscription management
USER STORIES:
- As a user, I want to activate my subscription using Google Pay, so that I can listen to every song
- As a user, I can change my subscription plan while I have an active subscription so that I can try other subscription plans within my current budget.
- As a user, my existing subscription should be renewed when it expires, so that I will not need to activate it manually.
3. WRITE ACCEPTANCE CRITERIA FOR YOUR USER STORIES
The purpose of acceptance criteria is to know when the user story is done from the product perspective. Acceptance criteria define the functionality, behavior, and performance required by the features so that the product owner can accept it.
It defines what is to be done so that developers know when the user stories are complete.
Here’s an example of acceptance criteria for the second user story example above.
User story
As a user, I can change my subscription plan while I have an active subscription so that I can try other subscription plans within my current budget.
Acceptance criteria example
- If a user is changing to a subscription with a higher value; the user value of the new subscription should be deducted from the user’s payment details immediately.
- If a user is changing to a subscription with a lower value; the new subscription becomes active at the end of the current subscription
- On subscription update, The user should receive a confirmation email stating thus; “Blah Blah Blah.”
Another user story and acceptance criteria example made in-house for a music streaming app.
User story
As a user, I want to sign up using my phone number so I can create an account on the platform
Acceptance Criteria
- The user should start with entering and verifying phone number before proceeding to enter their first name, last name, and email.
- The user should see a countdown of 30 seconds on the verification page before being able to click on the ‘Try Call’ option
- Upon verification, the user should be presented with the form to enter the first name, last name, and email
- The user device ID should be persisted in the database along with the user’s info when completing registration.
With these criteria stated, it will be apparent to the development team what needs to be implemented to consider the user stories done.
How we write user stories that prioritize user values.
At Sprinthub Mobile, we have gotten into awkward situations where there are user stories in the product backlog without clear user values. After some research and brainstorming, we came up with that the better way to write user stories is to write the user value first.
In order to <achieve some goal or value>, As a <typer of user>, I want to <do something>.
Example;
In order to occasionally report my concerns to the support team, as a user, I want to chat directly with support.
Using the approach above makes all user stories in the product backlog value-first. Because if you can’t come up with the value for the intended user, then the feature is not required. Writing user stories this way also helps in prioritizing user stories, so everyone knows what needs to come first.
Read More: How much does it cost to develop your app
SUMMING UP
User stories might not be agile in themselves but can help you to follow agile principles. Thanks to User stories, specialists like us can set project goals, realize user’s wishes and achieve the most desirable business results for our clients. We would also be glad to know your thought and experience in writing user stories – share your thoughts and expressions in the comments below!