User Stories Basics
User Story is a popular requirements modelling tool. In this post, we will learn about user stories basics, structure of user stories, INVEST theory for user stories. We will also look at an example user story model.
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 traveler.
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.
- Estimatable – 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.
INVEST guidelines can also be used to review the developed user stories.
More on User Stories
I am going to post more articles/Videos on this subject. These user stories posts are going to be:
User Stories 3C model (Article)
Techcanvass is an IT certifications training academy offering courses in Data Science, Business Analysis and Automation testing.
We are an IIBA Endorsed education provider (EEP) and iSQI authorized training partner. Our business analyst courses are for all the levels as shown below: