If you want to know “What Are User Stories And Why You Should Be Writing Them”, read the other article, but if you are already familiar with User Stories, it’s time to actually learn how to write a good one.
The most important thing is to look at the product (or a specific functionality) from the perspective of a person that will use, or experience it.
User Story Formula
We can easily craft a short and simple formula that will represent the user’s mindflow:
Based on a role:
"As a role person , I can a goal so that why"
Based on a class of user:
As a particular class of user , I want to be able to perform/do something so that I get some form of value or benefit
Make no mistake. “Simple” is far away from “Easy”. The process itself requires solid behavioral insights and your absolute focus on the user’s expectations.
This formula will help you build very simple, yet effective User Stories for any kind of user.
Let’s give them an example for better understanding:
As a user, I want a camera icon in the chat write box to capture and send pictures so that I can click and share my pictures simultaneously with all my friends.
This way, you make it extremely clear and easy to understand for developers, what type of user is expecting what kind of outcome from a specific functionality or feature.
Good practices
How to make sure your User Story is well written?
Here are a few practices to follow:
- Think like the User!
- Engage the whole team when writing a User Story (just make sure it won’t end up with the endless discussion and the idea pollution).
- Start from Epics and break them into smaller User Stories.
- Identify User Stories with numbers or letters.
- Indicate how much time is needed for each Story.
- Indicate priority.
- Clarify User Stories from a technical point of view (do not include technical requirements in a story!).
Wrong practices
Let’s flip the coin now. Make sure to do not:
- Use Epics for Tasks, or break them into substories.
- Use the stories that were not approved.
- Divide low priority Epics into user stories - it may be a waste of time.
- Include technical requirements.
Acceptance Criteria
By definition, acceptance criteria are “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.”
In other words, when the user is getting some precondition and do some action then he expects a specific result. Acceptance criteria are all the results that should satisfy his expectations.
Let's consider that you are chatting with a friend on your phone. You should be able to capture a picture and after clicking on a picture, you should be able to add a caption to the image before sending it.
But what If there is a problem with starting your phone camera during that? In this case, Acceptance Criteria will be an error message like ‘Camera could not be started’, or else.
What about technical requirements?
It’s all beautiful, but at the end of the day, the developer needs to have a piece of the clear technical information he can follow.
Again, don’t mix Technical Requirements with User Stories.
They should be used together, to complement each other, not to substitute each other.
User Story should deliver a meaningful context to the Technical Requirements so that the developer can clearly understand the functionality from the user’s point of view.
Here’s another example:
User Story:
As a team member I will have my “Kudos to spend” balance renewed every month, so I can give them to other users.
Technical Story:
In order to renew the “Kudos to spend” balance, the CRON on the Heroku must be configured to start each first day on a month. An endpoint for starting reset points feature must be created.
Summary
To sum it all up using User Stories bring many advantages to the development process, as it is a simple way of clarifying the product’s goals and functionality.
This can significantly improve the collaboration of different parties - users, product owners, developers - and bring a lot of useful insights from each one of them.
Being clear is extremely important in the development process, as it saves a lot of time and money.
Done well, they can help you avoid hours of additional communication and put all the resources into the execution.
Top comments (0)