User Story in Software Development

It is difficult to keep the customer requirements unchanged in the course of software development. When it comes to the waterfall approach to projects, the final ready-made product does not always correspond to the client’s initial desires. With the agile approach, the requirements can change, and all the parties involved have the right to exchange their opinions and suggest adjustments.

Agile methodology used in Scrum, Kanban and Extreme Programming doesn’t need heavy documentation. User requirements are expressed in the form of short laconic texts known as user stories. In this article, we will focus on the concept of user story and learn how to write it.

What Is a User Story?

A user story is a concise simple-language description of the required features in the program that the development team has to create. Being an important artifact in Agile development, it is widely used in Scrum, Kanban and Extreme Programming. This instrument helps gather the requirements based on each potential user’s needs and contains the following details:

• End-user types
• End-user desires regarding program features
• The explanation why the end-users want these features

A wholesome user stories approach to software development shouldn’t include just a written explanation of requirements, but also a sequence of conversations, during which all stakeholders discuss the expected features with the development team.

Then, the confirmation stage takes place, to make sure that the story is compliant with the requirements. Most often, user stories are written through the cooperative efforts of all product team members. All specialists regardless of their qualifications can help in the creation of user stories.

Even a person without deep coding knowledge can offer advice due to such characteristics as plain natural language usage. No technical skills are required, just comprehension of user-specific challenges that the team has to address.

The Role in Software Development

During the software development lifecycle, client requirements may change. Developers reveal more peculiarities about the program they create, and it’s impossible to stick to initial requirements all the time, as progress and change of perspective is inevitable.

That said, software engineers often adjust the initial requirements along the way to produce usable software ready for service. User stories offer short and simple descriptions, thus reducing the time that would otherwise be devoted to creating lengthy complex explanations.

In this case, the main focus is on communication with the customer, which assists in understanding all the details that need to be taken into account. It helps to develop the program in less time and avoid mistakes caused by misunderstanding of requirements.

What Does a User Story Look Like?

There are different methods product owners can use to create a user story that is both concise and informative. Further, we will examine the three most popular ones.

Role-Goal-Benefit

Every user story has three permanent elements that name the customer (who?), state the needed feature (what?) and express its intent (why?). This template is known as the role-feature-reason, or role-goal-benefit model.

“As a (type of user) I want (some feature) so that (some reason).”

The simple formula helps the development team focus on user personas and their individual characteristics and needs, rather than on specific technical terms. This approach leaves engineers the freedom to come up with the most efficient creative solution.

• Role

This element means “who?” and refers to the client or end-user of the feature under development. There could be multiple user stories and multiple would-be users of the software, so a definite name is necessary.

For example, if we develop a web portal for college, the potential users could be the applicants, undergraduates, graduates, students’ parents, professors, advisors, mentors, etc. Each of the user groups has its own specific needs and desires, so it’s important to keep in mind the different perspectives and points of view.

• Goal

This is the answer to the question “what?”, where the requirement is described. Make sure it is written in a user-friendly manner without complex IT terms and lines of code. It should be written so it’s understandable to the end consumer, not a software engineer.

• Benefit

This is the “why?” part of our user story. It explains the reasons for the introduction of the technical features, the certain value that the user can get from it. It helps in getting the customer’s intent right and prioritizing user stories when planning agile sprints.

The Three C’s Model

Development teams use the Card, Conversation, Confirmation approach to tell apart informal customer-centric user stories from official requirements, documents and use cases. Here are the details of each element of this formula:

Card is a physical token. Being a material object, it has a clear requirement written on it instead of an abstract and vague verbal explanation. The requirement is usually written in a short form (preferably one and not more than two–three sentences) and complies with the role-feature-reason format.

Conversation is verbal communication between all the parties involved in the development process. This can include clients, potential users, software engineers, UI/UX designers, and QA specialists. Afterwards, the results of this communication are put into writing.

During the meeting, the team can discover new features that need to be developed. Often a single card can be split into a few new ones, and sometimes one card can be substituted with another, or even removed. As a rule, the team and stakeholders communicate verbally, but sometimes they can share documents, analytics, or results of acceptance tests to support their ideas.

Confirmation is the formal approval of the completed project by the customer. It is the acceptance test during which clients or their representatives check if the story was completed in accordance with the customer’s intent. Then the story is considered done and accepted.

INVEST Method

You can check whether your user story is written properly with the help of the INVEST method. Each letter stands for a separate criterion that characterizes a high-quality, insightful user story.

Make sure your story meets all these characteristics:

• (I) Independent. A single development team should be able to create the feature described in the user story without the necessity to ask another team for help.
• (N) Negotiable: The text should contain only the customer’s specifications without superfluous details. It should not be set in stone, so that in the future the team can make adjustments to it.
• (V) Valuable: The author of the user story has to express the actual importance of the feature described in it. In terms of the Three C’s, it is stated in the card in the intent part, then it is discussed during the conversation and finally approved by the customer during confirmation.
• (E) Estimable: It is important to prepare all the needed information to properly estimate user stories, set priorities and ensure that one story can be completed within a single sprint.
• (S) Small: A user story should be small-scale and simple enough for the development team to finalize in one sprint. In case it is unattainable, the team should divide it into several parts, each of them equal to one sprint in time.
• (T) Testable: There should be definite requirements and conditions for the user story to be accepted by the customer. A user story should be clear and objective. We recommend specific measurable criteria, including test automation.

What Are User Stories Used For?

In the agile environment, user stories are implemented to capture the functionalities and characteristics end-users need from the system under development.

Often entries in the backlog in Scrum agile frameworks are expressed in the form of user stories. Then they are added to the sprint. It helps software engineers view the tasks as far as would-be customers are concerned.

In Kanban methodology, the project task is based on a user story. Product owners acting on behalf of the clients gather user stories in the backlog and prioritize them accordingly.

Kanban is different from other methodologies as it is more concentrated on definite tasks and not on the elements of the development workflow. So, it is more flexible and product owners can rearrange prioritization without disrupting the process.

A user story is viewed as a criterion for product acceptance in Extreme Programming. Prior to writing code, software developers utilize user stories to create acceptance tests. These are implemented to set up estimates, which helps save more time for the team and deliver high-quality code.

Examples of User Stories 

• As a UX designer, I can store all my projects in one place, so that I can find the ones I need quickly when required.
• As a senior recruiter, I want to be able to review the current status of candidates for all positions, so that I can arrange their interviews accordingly.
• In order to carry out email campaigns more effectively as a sales manager, I can send out messages automatically.
• To gather feedback from loyal customers as a marketer, I should be able to find their contact details in the database quickly.
• As a student, when checking my schedule on the university web portal, I want to set filters on professor names, because I want to attend only lectures of certain professors.

Advantages of User Stories

Let’s consider the advantages that implementing user stories in SDLC can bring:

• The more precise expression of customer desires.

It is achieved with the help of three constituents of just a single short sentence:

• User role
• User wishes
• User aims

This approach helps the collaborators stay customer-centric and concentrate on the desires and ultimate objectives of end-users.

• Improved collaboration due to alignment of all potential users’ needs.

The development process becomes focused not only on the aims of a particular feature, but also on the reasons why the feature is implemented. Sometimes it is even substituted with another one if it is more functional and still meets the customer’s needs.

• Decreased risk, because user stories are focused only on the most important of the customer features. It helps the team to eliminate possible misinterpretations and adhere to the set timescales.
• Сost-effectiveness.

Due to its short and simple nature, written in plain informal language, a user story is a time-saving instrument. No need to load it with heavy details.

• Versatility.

Can be used to introduce large and complex features as well as small and simple ones.

• Proved commercial value.

The software delivered is exactly what the customer needs. It is provided thanks to the established structure of the user story implementation process: the customer states the goal of the development in the card, suggests changes during conversations if needed, and confirms that the product complies with the desired characteristics.

Creating User Stories

Step-By-Step Guide on How to Write a User Story

• Describe the End Goal

Typical user stories are all about achieving the customer’s ultimate objective. So, when creating a user story, bear in mind that it is extremely important not to overlook the definition of “done” in the task.

• Define What Needs to Be Done

We would also recommend you to provide information about what has to be done to perform the task described in the user story. Usually, this is done in the form of additional documents with assignments to the team members responsible for this kind of work.

•  State User Roles

You have to mention who is the end-user or customer in the user story. If there are multiple end-users, there will be a number of user stories for each one of them. This approach will help software developers remain customer-centric and concentrate on the real needs of actual users.

• Specify Steps

If you decide to implement a user story map, the whole development process will be viewed as a number of subsequent chores that need to be done. This can help split the big task into several smaller subtasks. Each one constitutes a separate user story.

• Learn Feedback

To create a product of first-rate quality, one should not forget about gathering feedback promptly. Feedback from all team members is welcome. It will help in evaluating the complexity of development, defining the scope of work, and development optimization.

Customers can give you precious advice on how to improve the text of the story or give insight on extra features that they would like to see in the product, which can lead to the emergence of additional user stories or even a transformation of the whole perspective.

•  Choose Short Stories for One Sprint

A complex user story can’t fit into one sprint, so it is separated into a few. As a rule, it shouldn’t take more than 1–2 weeks to develop one user story task. Using this approach, developers can deliver new features more quickly and switch to other tasks.

Advice for Creating User Stories

• Make sure the descriptions of user stories are not excessively long.
• Try to perceive the software from the position of the end customer.
• Define the confirmation details in advance, before the software is developed.
• Carry out estimation procedures so that you can efficiently distribute the tasks among the team.
• Remember to define the set of requirements together with both end customers and software engineers. Do not leave this task either for the customers, or the developers. Consistent collaborative work is of utmost importance.
• Do not underestimate the meaning of conversation between the development team and business stakeholders. It helps define the customer’s ultimate intent and clarify all the necessary details.

Story Maps

User stories are primarily aimed at showing the customer’s intent and are structured to clearly and pragmatically display it. Nevertheless, they do not present the entire idea of the program under development.

Usually, a story describes a certain action that users want activated at a certain point of their experience. For a more wholesome understanding of the program, software development teams use story mapping. A good story map can reveal overlooked tasks and details that otherwise may have been missed.

So, why should you use story maps?

• Easier task prioritization and decision-making
• Reveals minimum viable product
• Better requirement visualization
• Helps to adhere to customer-centric approach
• Makes sure the interests of each party are represented
• Holistic view of product delivery
• Detailed illustration of the customer journey

Elements of the User Story Map

More often than not, user story maps contain three structural elements. In some cases, with complex enterprise-level projects,  they may involve four elements, splitting the usual third element into two different ones. Those  elements are usually as follows:

• Activities — The most important goals that must be achieved in the project. These are the main functions that the software should be able to carry out.
• Tasks — The subsets of activities. Each activity comprises several similar tasks.
• Epics/user stories — Each task is split into several epics or user stories. For complex projects, you may classify epics as the third-level element, and user stories as the fourth. The difference is that epics are mainly considered to be larger units of work that can be divided into more detailed smaller units, such as user stories.