How to write effective user stories?
User story is a powerful technique to capture early stage requirements. User stories capture the WHO, WHAT & WHY of a requirement and that makes it easier for every one to have an early shared understanding. However, writing user stories like any other requirements needs an understanding of what are the characteristics of a good user story.
So, How can we be good in writing effective user stories? Before get into that, lets first understand the basics of user stories.
What are user Stories?
User Story is a popular format of representing a feature or user requirements of a software system from an external user perspective. The format comprises of three key elements as shown below:
As a <User role>
I want <to do something>
So that I can <achieve some goal>
The user role represents a type of user (and not an individual user). The requirements are presented from this user role perspective – <to do something>. The third part of the user stories is the purpose of the action.
The user stories, not only, represent the system feature/requirements, it also explains – why it is being done?
User Story Example
Let’s a simple example to understand the user stories basics better. A customer is looking to get a travel portal for flight tickets booking. One of the requirements for this portal is the search of flight tickets for a business traveller. The user story for this case can be presented as shown below:
As a <User>
I want <to search for flight tickets as per my schedule>
So that I can <so that I can attend a business conference>
The good thing about user stories is that every stakeholder (customer as well as developers) gets a complete idea about the requirements.
Writing good user stories
What are the characteristics of a good user story? Well-written user stories are critical to the success of a project. INVEST represents the characteristics of a good user story as explained below:
- Independent – User Stories should be as independent as possible.
- Negotiable – User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.
- Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
- Estimable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.
- Small – User Stories should be small. Not too small. But not too big.
- Testable – User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
In addition to INVEST principle, some important points should also be considered while writing user stories:
- At the time of writing user story, the requirements would not be very clear. It is advisable to capture all the assumptions and constraints related to requirements / user stories. These assumptions provide the basis for managing risks.
- Ensure that user stories are written clearly and have no ambiguity. A very famous example is usage of word bi-weekly. Many people treat it as once in 15 days, where as other group of people may consider this as twice in a week.
- Use a mutually agreed user story format as there is no standard format of a user story and that can lead to confusion.
- Clearly mention the Acceptance Criteria. Acceptance criteria help in the definition of DONE? Done definition helps in identifying when a user story is completed
- It’s always advised to keep refining the product backlog. This will ensure that new user stories are getting added to the list and also the stories which were on low priority might get enough attention.
We will be happy to hear if you have any suggestions on writing effective user stories.
Techcanvass offers IT certification courses for professionals. We offer Business analysis, automation testing, DevOps and RPA certification courses. We are an IIBA endorsed education provider (EEP), iSQI ATP (for Certified Agile Business Analyst Training) as well as Agile Testing alliance partner for CP-SAT certification training in Selenium.