Planning is an indispensable part of any project management. When following the Agile methodology to manage a project, there are a number of approaches that can help a team to plan the development cycle and ‘User Stories’ are one of them.
A User Story is an approach to formulating a product backlog. In simple words, it’s a to-do list for the scrum team wherein the work to be done is divided into functional increments. The idea behind creating user stories is to break down a product into small, shippable deliverables.
Just consider a User Story to be a conversational document that comprises of project requirements. It enables a business to communicate with the scrum team about their expectations from the end product. Along with the information about what needs to be developed, a user story gives an estimation of the time in which a particular item is completed.
So, now that you know what a user story is, you would want to know who creates it, when they are created, how they are different from requirement gathering, and most importantly, how to write one. In the later segment, we will answer all your queries related to user stories and will have a detailed discussion on how to write a great user story.
Who Writes the User Story?
Anyone in the scrum team can write user stories. Ideally, its the responsibility of a product owner to create a backlog for the product and come up with what needs to be created by the team. But, over the course of the Agile project, the entire scrum team, i.e. the product owner, scrum master, and developers can (and should) contribute to the user stories.
Requirement Gathering vs User Stories
A user story focuses on the problem statement of the customer. Therefore, when creating user stories, the aim is to consider user experience and focus on what the end-user of the product would be able to do with it. Thus, the process of writing user stories involves breaking down the product into small, iterative, functional deliverables. In contrast, the requirement gathering process focuses on the functionality of the product, i.e. what the product should do.
When to Write User Stories?
User stories can be written anytime during a project. It is generally written by the product owner at the initial stage of the project where he has to create a backlog. However, as product development continues, the entire scrum team continues to contribute to the user story. So, writing a user story is an ongoing process.
How to Write a User Story?
When writing a user story, remember that it aims at defining “what needs to be done” instead of “how it should be done”. Generally, a simple template is followed while writing stories that help the scrum team to properly define what needs to be done by the team.
As a < type of user >, I want < some goal > so that < some reason >.
If we go with this template, there are three things that need to be defined in user stories:
- Persona (Who): While writing the user story, it is important to understand the type of user who will interact with the solution or for whom the product is developed. While writing user stories, it is necessary to understand and define the user of a particular feature or functionality. For example: If a product is designed for a user ‘John’, then the user story creator should know who John is, in terms of his interests, personality, expectations, age group, and more.
- Actions (What): What needs to be created is the crux of a user story. Thus, it should have a mention and detail of what a user can do with the app. For example, a user can add the product to the wishlist, move products from wishlist to the cart, sort products on the basis of various parameters, make a payment, add an address, etc. The action items for the user should be clearly defined in a user story.
- Benefit (Why): While writing the user story, the scrum team should be clear about the benefits that a certain action will deliver to the users. For example: If the login page has a “forgot password” feature, then the reasons for its introduction in the solution should be clear.
Once a user story is created with Who, What, and Why in mind, it will look something like this:
As a [customer], I want [a payment feature] so that [I can easily make payment for items I purchased online].
In addition to the above-mentioned factors, it is important to consider the INVEST formula in mind while creating user stories. The INVEST formula shares the accepted criteria to assess the quality of a user story.
According to the INVEST formula, a user story should be:
- Independent: User stories should be independent, i.e. it should be possible for a team to develop and deliver them, without any dependency upon one another.
- Negotiable: As discussed above, writing user stories is an ongoing process. When a product owner creates a backlog, the rest of the team (developers, scrum masters), and even the business stakeholders should be able to contribute to it. It shouldn’t be a contract and rather should be a mode of conversation between the development team and the stakeholders.
- Valuable: The user story should deliver some value to the customers. Every feature or functionality that’s added to the story should let the user do something and offer some benefit.
- Estimable: A user story is a small, shippable deliverable, and thus should be estimable. This makes it easy for the scrum team to prioritize the features and fit them into sprints.
- Small: Stories shouldn’t be too big. They should be divided into small deliverables that are usually done in 3-4 days.
- Testable: A quality analyst must be able to test the deliverable of a user story.
Want to Create User Stories for your Project?
Do you have an idea ready for execution? Get started with it by creating a product backlog for your solution. At Daffodil, we help businesses to develop comprehensive software solutions, of which building user stories is an important part. If you too want our experts to write user stories for your product, then share your idea and requirements with our team by setting up a 30-minute free consultation with us.
