A key element of the Agile mindset is putting people first. Agile is a user-centered approach. It shifts the focus from just coding and designing to delivering real value to your end users.
User stories put actual end users at the center of the conversation. User stories use non-technical language. It provides context for the teams and let them define what benefits the products will bring to their target audience.
User stories drive collaboration and creativity, and a better product overall. After reading a user story, the team knows why they are building what they are building and what value it creates. In this video, we will be discussing five points related to the user stories. What is a user story?
Why do we write user stories? How do we write user stories? Who write them? And when do we write them? So let's get started.
A user story is the smallest piece of work that represents some value to an end user. It contains the following elements title description and acceptance criteria the title of a user story follow a basic formula as role I want an objective so that I can achieve a motivation The use of story defines a functionality. It is expressed as a persona, the role, who are we doing this for?
That is performing an action, an objective, so he can satisfy a need, the motivation. An example of a user story could be As an Uber passenger, I want to see several available drivers in my area so that I can choose the closest one to me. We must remember that the title of a user story must map a single functionality of our product or service.
Let's look at the description. The description of a user story helps to give context to that story. The description may contain a small explanation of the user journey, some use cases, and in general, any explanation that helps to better understand the title.
The description should not be thousands of words, but it should contain any good context that help clarify what is being expressed, such as pictures or links to the design. Now, along with the title in the description, one last important element that should be included in the user story is the acceptance criteria. These are a set of conditions that helps us to validate the implementation of our user story and to confirm when it is completed.
If we take our previous example as an Uber passenger, I want to see several available drivers in my area so that I can choose the closest one to me. Acceptance criteria for this use of Stravia could be The app shows only the drivers that are within an area of 4 km from the customer The app shows maximum 10 drivers that are in the same area as the customer A customer can check the profile of these drivers, including their picture and rating We are able to understand the value of a user story with the title and description, and the acceptance criteria help us understand some key characteristics that require special attention during implementation. So going through the acceptance criteria with the team at the time of writing the user story is the best way to fully develop the functionality.
So what is the benefit from writing a user story? User Stories emerged as a result of a need to break down projects into smaller, incremental segments for sprints and iterations. If you were ever involved in working with Agile Framework, you already know that both Scrum and Kanban teams greatly benefit from writing User Stories.
In Scrum, User Stories are added to the sprint backlog and worked on over the duration of the sprint. In Kanban, teams accumulate stories in a backlog and then run them one by one through their workflow. Working on user stories helps current teams make estimations, prioritize and plan sprints, leading to more flexibility and greater agility. And thanks to stories, campaign teams learn how to manage work in progress, which help them to constantly stay on track and refine their workflows. User stories have other benefits that are common to all agile teams.
They keep you focused on the user and the business value. It helps to make your product not only well-built from the technical perspective, but also useful to the end users. User stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal. It enables creativity.
Stories encourage the team to think critically and creatively about how to best solve the end goal. Your project becomes more manageable. User Stories is the best way to work with small and estimatable elements, rather than with big complex tasks.
And finally, they inspire the team and create momentum. With each story closed, the team loves this sweet feeling of a small win, which motivates them to work even harder. Let's look at how to write a good user story.
The common user story templates include the user, the action, and the value, and it typically looks like this. As a type of user, I want an action so that I can achieve a reason or a value. Before writing a user story, you should know who the end users or the persona of your product are, and more important, what needs they have which you are trying to cover. It is all about the user, not about the developers, and not even about the product owner. Each story should bring a value to some group of your end users.
Feel some empathy. Give your user a name. Think of his habits, what issue your app is going to get resolved for him, and how you're going to make this path easier and faster. Now that we have a few groups of end users, the next step to do is define what functionality each user expects.
How he's going to use the product. Some basic rules to remember when writing an action for a user story is to have one action per story. If you want to write something like, as a customer, I want to browse items and then add them to the cart, it is better to split it into two different user stories. One, as a customer, I want to browse items, and the other one, as a customer, I want to add items to the cart.
Describe an intention, not a feature. For example, instead of I want to manage my profile, create a few stories like I want to be able to register my profile, I want to be able to upload my profile photo, I want to link my credit card to my profile. Each user story will have a different value. Finally, the last piece of our user story someplace is dedicated to the value.
The value that the users will get after performing an action. What's the overall benefits they are trying to achieve? What is the big problem that needs solving? Each story should contribute to the general goal of your product.
And if you can't answer what value this user story brings to the end users, and your products as well, then you're doing something wrong. User stories are an essential element of the agile approach that can bring many benefits to your project. However, it's important to write them correctly, which requires some time and skills. A good user story meets the INVEST criteria, meaning that they are independent of other user stories.
User stories can be developed in any sequence. User stories are negotiable. There must be a conversation between client and development team, not a closed contract.
Valuable. Each user story must add a value to the product. Estimatable. Each user story must be able to be estimated in relative sizing, such as story point or t-shirt sizing. Small.
Enough to fit in one sprint and to be completed. And finally, testable. Each user story must be able to be validated and tested.
Writing user stories that follow the user story format is a good starting point. Evaluating them for effectiveness against the invest goals keep the user stories small, functional and testable. So who writes the user stories? The product owner has the responsibility to make sure a product backlog of user stories exists.
However, it doesn't mean that the product owner is the one who writes them. The more people join in the conversation the better, and anyone can contribute and write user stories. The responsibility of the product owner in this case is to confirm that they are matching the invest criteria and to prioritize those user stories in the backlog. Finally, when do we write the user stories? User stories are written during the whole life of the product.
Usually, a story writing workshop is held at the start. The team members will participate with the goal of creating a product backlog that describes the functionality to be added over the course of the product development. Some of these user stories will be big ones that will later be split into smaller ones, and that can fit into a single iteration. On top of that, new user stories can be written and added to the product backlog at any time and by anyone.
I hope this video gave you a good understanding of user stories. Please leave us a comment and follow us for more content. Thank you!