What are “User Stories” and what are they used for?

Updated IT News

Within software development and product management, a user story refers to an informal description – written in a natural language – of one or more functionalities of a software system. It is a crucial part of an agile approach that fluctuates between writing down requirements and discussion.

In this article, Bocasay, an offshore IT outsourcing company, provides an overview of the concept of ‘user stories’ and explains their key functionalities.

Discover how to take advantage of ‘user stories’ with Bocasay, IT specialist in offshore outsourcing ©kanchanachitkhamma
Discover how to take advantage of ‘user stories’ with Bocasay, IT specialist in offshore outsourcing ©kanchanachitkhamma

Definition: what is a ‘user story’?

A user story is a tool used within agile software development in order to capture a description of the software’s functionality from the perspective of the end user. They describe the types of software users, what they require from the actual software and why. In addition, user stories enable you to create short descriptions of your software requirements.

It is common for user stories to be recorded on index cards, post-its or project management software. Depending on the project, user stories can be written by different stakeholders, such as:

  • customers,
  • end-users,
  • managers
  • and members of the development team.

Within the Srcum method, the Product Owner is the person responsible for writing the user stories.

Why are user stories valuable?

User stories provide important context for your team, ultimately linking tasks to the value they provide.

User stories are, quite intuitively, user-centric. In addition, the series of stories enables the development team to focus on solving real user problems.

More importantly, user stories boost team spirit. Once the end goal is defined, team members can work together to determine the best way to serve users and achieve that goal.

Last but not least, user stories improve project dynamics. As the story unfolds, the development team enjoys the small challenges and triumphs that create a positive momentum.

According to Ron Jeffries, an agile user story consists of three parts: 

  • The map: A description of the story. Used as an outline and reminder.
  • The conversation: The dialogue of the story used to flesh out the details of the story.
  • The confirmation: A test that communicates and documents details that can be used to determine if a story is complete.

User stories have many benefits, but perhaps the most important is that each user story becomes a placeholder for future conversations.

How to write a good user story

End-users are the ideal people to write user stories.

When using the Scrum method, the Product Owner prioritizes the user stories in the product backlog. The highest-priority stories are extracted from the backlog and processed in Scrum sprints.

The key to writing effective user stories is to determine who, what and why.

1. Define the end user

Who will use your product?

Before writing a User Story, you need to know who the end-users of your product are. And, more importantly, what software needs you are trying to cover.

For best results, dig deeper into your audience. Instead of simply naming users by role (e.g. “a driver”), try to create a type of “buyer persona” of sorts.

👉 Don’t just always think of your users as external customers. Indeed, most of your stories are about them. However, it’s also true that internal users such as administrators and editors should also be considered.

👉 Be empathetic. Give the “user” a name. Think about their mobile habits, the problems your app helps solve, and how you can make that process easier and faster.

Example of an effective story title that highlights the target user and their action: “Clothidle from accounting is looking for a customer record.”

2. Specify what the end-user requires

What do your end-users require from your software product?

The main rules to keep in mind when writing Kanban user stories or Scrum actions are:

👉 One action per story. Describe the intent, not the functionality. For example, instead of “I want to manage my profile”, I create several stories such as:

  • “I want to be able to sign up.”
  • “I want to upload a profile picture”.
  • “I want to associate a payment method with my profile.”

Each story has a different value.

👉 Keep it short. The user doesn’t care which library they need to use in order to browse the list of items. So leave out all the technical details.

𝔻𝕚𝕕 𝕪𝕠𝕦 𝕜𝕟𝕠𝕨 𝕥𝕙𝕒𝕥 𝕪𝕠𝕦 𝕔𝕒𝕟 𝕓𝕖𝕟𝕖𝕗𝕚𝕥 𝕗𝕣𝕠𝕞 𝕒 𝕥𝕖𝕒𝕞 𝟙𝟘𝟘% 𝕕𝕖𝕕𝕚𝕔𝕒𝕥𝕖𝕕 𝕥𝕠 𝕪𝕠𝕦𝕣 𝕣𝕖𝕞𝕠𝕥𝕖 𝕀𝕋 𝕕𝕖𝕧𝕖𝕝𝕠𝕡𝕞𝕖𝕟𝕥 𝕡𝕣𝕠𝕛𝕖𝕔𝕥𝕤? 𝔹𝕠𝕔𝕒𝕤𝕒𝕪, 𝕖𝕩𝕡𝕖𝕣𝕥𝕤 𝕚𝕟 𝕠𝕗𝕗𝕤𝕙𝕠𝕣𝕖 𝕀𝕋, 𝕔𝕒𝕟 𝕡𝕣𝕠𝕧𝕚𝕕𝕖 𝕪𝕠𝕦 𝕨𝕚𝕥𝕙 𝕥𝕒𝕝𝕖𝕟𝕥𝕖𝕕 𝕕𝕖𝕧𝕖𝕝𝕠𝕡𝕖𝕣𝕤 𝕥𝕠 𝕒𝕔𝕔𝕠𝕞𝕡𝕒𝕟𝕪 𝕪𝕠𝕦 𝕚𝕟 𝕪𝕠𝕦𝕣 𝕔𝕠𝕞𝕡𝕒𝕟𝕪’𝕤 𝕡𝕖𝕣𝕗𝕠𝕣𝕞𝕒𝕟𝕔𝕖 𝕒𝕟𝕕 𝕖𝕧𝕠𝕝𝕦𝕥𝕚𝕠𝕟. ℂ𝕠𝕟𝕥𝕒𝕔𝕥 𝕦𝕤 𝕥𝕠𝕕𝕒𝕪 𝕒𝕟𝕕 𝕒𝕤𝕜 𝕗𝕠𝕣 𝕪𝕠𝕦𝕣 𝕗𝕣𝕖𝕖 𝕢𝕦𝕠𝕥𝕖!

3. Describe product benefits

Imagine that you are the end-user and you are talking to the  product developer. You need to explain the benefits that the end-user will get from using the product to the developers.

For example, in the case of an online ordering application:

As a customer, I want to receive notifications when there are new hot deals, so that I never miss the best deals.

👉 Users are notified, they use the app more often, retention rate increases.

As a manager of an online clothing site, I want to complement the product description with a photo of the worn garment to allow customers to project themselves.

👉 Users are happy to be able to see the photos, sales increase and so does revenue.

4. List the acceptance criteria of the stories

Acceptance criteria define the boundaries of user stories. They are used to confirm that a story is complete and functioning as expected.

The criteria can include the following:

👉 Functional: identifying the user’s tasks, functions, or business processes.

👉 Non-functional: related to design and user interface.

👉 Performance: related to performance metrics, for example, load time.

Consider offshore IT for your next project ©Canva
Consider offshore IT for your next project ©Canva

The advantages of user stories

The main advantages of user stories include the following:

Greater flexibility: user stories are less technical and can be adapted to a changing environment.

Simplified format: user stories are written in a plain, natural language. This eliminates confusion and helps to better understand what customers require.

Improved collaboration: When team members are aligned to a common goal, they can collaborate better and more easily with other project stakeholders.

While writing user stories has a number of benefits, product owners should also consider the potential drawbacks.

The drawbacks of user stories

Here are some pitfalls to avoid when creating user stories:

Incomplete stories: although the wording is supposed to be informal, user stories are sometimes too vague and leave out necessary details.

Narrow focus: user stories focus on a single requirement, which makes them difficult to scale and can cause teams to lose sight of the big picture.

Time: writing good user stories takes time. It requires extensive research and regular communication with stakeholders, which is often overlooked.

Before starting to work on your user stories, take the time to identify potential risks and gaps and figure out now how to solve them.

Visit our Website - related posts from same category