August 17, 202015 Min Read

How to write user stories in software development

A user story is short, general explanation of the software feature from the perspective of end-user. Its purpose is to depict how specific software functionality will deliver value to users. As delivering value is the key element of agile methodology, user stories in software development are crucial tools for creating valuable software, as they put the user in the centre of the conversation. Hence, it is important to understand user stories and know how to write them. In this article, we will define what user stories are, why companies use it, who can write user stories, how to write a good one, and more.

What are user stories in software development?

A user story is a small, descriptive piece of development work, designed to accomplish a specific goal within any given software product. It is a simple description of a feature, written from the perspective of the user, who desires the new capability. The purpose of the user story is to create an understanding of feature from the perspective of the end-user. It describes user type, what the user wants, and why. User stories look at the software features from the different end-user's viewpoint. This way, they represent the desires and needs of a full customer base of the software, rather than a single user.

What do user stories look like?

Just because user stories are for software development, does not mean that they should be filled with technical terms. On the contrary, user story should be simple, clear and written in everyday language, so that everyone (and not just developers) can understand it easily.

The structure of the user story is as follows

As a [user], I [want to], [so that]

Let's break it down:

User: For whom are we developing the software? Who will need specific functionality that we are creating? It can be a visitor, customer, user, or a system admin. Based on the software, you might have more specific user persona, such as project manager, team leader, teacher, driver, passenger, and more.

Want to: What does the user want to achieve? Here we describe the intent of the user persona, not the functionality of the software.

So that: What is the benefit that the user wants to receive? What is the problem of the user that we want to solve with new functionality? This part answers these questions and helps us see the new feature in a bigger picture, to deliver the value that the user wants to get.

Example of a user story in real life:

As a student, I want to be able to check mistakes in my test so that I can prepare for the next exam better.

Example of a user story in software development:

As a user, I want to save items in a wish list so that I can purchase them later.

Different types of user stories in software development

There are different ways to format user stories. Usually, companies try different types and write user stories according to the templates that suit their needs and working styles better.

Who - What - Why statemen

One of the most commonly used types is what "who - what - why" statement. Let's take a look at the example to understand it better.

As a [who], I want [what] to [why].

As a visitor, I want to sign up with my Facebook/Google account to complete a registration process faster.

User - Goal - Reason statement

This statement is very similar to the previous one with its structure. It also shows who the user persona is, what does she or he wants to achieve and what is the reason behind it.

As a [user persona], I want [some goal], so that [the reason].

As a customer, I want to save my credit card information, so that I do not have to fill it in next time I make a purchase.

Given - When - Then statement

This statement is different from the other two. While it still has a user persona in the heart of it, it describes the function more.

Given when the profile page is open when I upload a profile picture and hit the update button, then the profile picture is updated and the new one is visible.

User story vs use case: What is the difference?

To write user stories in software development, first, you need to understand the difference between a user story and use case. User story and use case share some similarities. They both use the natural language of the business, describe a specific way to use the system, and have a goal and the user in the centre. Because of that, sometimes, they are wrongfully considered to be same or interchangeable.

However, user stories and use case have differences, because of which both of them are used independently from each other.

What are these differences?

User stories have the following elements: the user persona, its goal and the reason. Use case consists of the actor, flow of the events and post-conditions. (Depending on the use case template, it might or might not include some more elements.) User stories do not contain many details. They outline the user, goal, and reason.

Use cases describe the interaction between the users and the software (and possibly other systems). While user stories are brief and more general, use cases are a complete description of every possible interaction of the user with the system.

The purpose of the user stories is to depict the raw need of the user. Use cases, on the other hand, describe the behaviour developers need to build into the software to meet the need of the user.

Both user stories and use cases are helpful tools. When writing user stories in software development, you need to keep these differences in mind and separate them from use cases.

Characteristics of user stories

When you write a user story, you should take into account some characteristics of it, to ensure that it meets the needs of the development team.

These are the two main characteristics of a user story:

It should describe the shortest user interaction.
It should include acceptance criteria for functional and non-functional requirements.

To apply more specific characteristics and criteria to your user stories, you can use the INVEST acronym while writing it. It includes the concepts that make up a user story the development team can use easily.

INVEST acronym:

• Independent

• Negotiable

• Valuable

• Estimable

• Small

• Testable

Let us take a look at each one.

Independent

A user story should be self-contained and as independent as possible. Developers should be able to work on the user stories in any order. It will allow them to prioritize and work on the most valuable user stories without having to complete the less valuable ones first. In other words, there should not be any dependencies between the user stories.

Negotiable

A good user story should leave the space for some discussion. It should give an idea about the essence of the desire user has. User stories in software development are not contracts. They should be negotiable, for only in this case can the development team create the best solution for the needs.

Valuable

Every user story should create value for the users. The development team should be able to work on the most valuable user stories first.

Estimable

When you write a user story, you should ensure that developers will be able to understand it and get an idea of how to implement it in a system.

Small

While user stories need to be short, they also need to be small. As a user story needs to describe the shortest user interaction, the implementation should not take more than 3-4 days on average. This time should include all the work that is required to mark the story as done.

Testable

Every user story should be testable and have objective acceptance criteria. It will help the team to determine the completeness of the story. It is best to avoid the use of vague terms such as fast or bug-free instead, use the measurable ones.

The Three C’s of User Stories

If you are just getting familiar with the user stories in software development, you need to understand the Three C's of user stories.

Good user stories consist of three key elements: Card, Conversations, and Confirmations.

Cards

You should be able to write a user story on a small note card to contain the most crucial information efficiently. To have the representative user stories, it is advised to create them for each type of user. Write a separate user story for every user type on a card in a standardized form. It can be a who-what-why statement or some other templates that were mentioned above.

Conversations

Conversations are discussions that happen between the project team and the stakeholders before placing user stories in the sprint. The exchange of thoughts and opinions is the indivisible part of the process. It helps the team understand the matter better and get additional knowledge for successful implementation.

Confirmation

Finally, all user stories should have acceptance criteria. They are used to confirm the successful implementation of the user story. Usually, the team sets the acceptance criteria during the conversations. It demonstrates when the user story is complete and works the way the user intended.

Who can write user stories?

Now you know what user story is and what are the types and characteristics of it, but who can write user stories in software development?

It depends, and the answer is not the same for every company. In bigger companies, usually, the product owner writes them. In smaller companies and new start-ups, it can be even CEO or CTO.

However, generally, every member of the team should be able to write user stories. It can be a product owner, project manager, or anyone from the team who has a communication with the client about the project.

How to write user stories in agile software development

Here is the five-step process that will help you write great user stories.

Step one: Define users

The main part of the user stories is the user. Before you start writing, define who are the real users that will be using the software. Create as many different user personas as needed.

Step two: Assign personas to stories

Different users of the system will have different desires and goals. To cover all of them, assign personas to each user story.

Step three: Collaborate on stories and expand with details

Add details to your stories. It will help you see the bigger picture and reveal the new points you have not thought of yet.

Step four: Decompose to smaller implementable stories.

After expanding your stories, they will include more information than a single user story needs. Now it is time to decompose them to smaller, implementable stories that the team will use in development.

Step five: Add conditions of satisfaction

The finals stage is to add conditions of satisfaction. With it, the team will know what are the criteria for completing a story.

Tips for writing a good user story

The following tips will help you in the process:

1. Do not write user stories as tasks

You should always keep in mind that user stories are for definition. While the development team will use them for defining the tasks in the future, you should not write stories as tasks. Moreover, one user story might need a series of work for complete implementation. If you try to keep all the tasks in mind when writing the user story, it will not serve its purpose.

2. Decide what done user story looks like

User stories show the needs of end-users. Thus, keep in mind the end state of the user story when you write it. This way, the development team will know when can they mark the work as complete and move on other cards.

3. Stay precise

Remember, a good story is solid, small and accurate. Do not try to include all the information or all the users' goals on one card. Even when they seem similar. Write one user story for each user. It will help you get the full picture from the perspective of every user persona.

4. Understand the user and think like one

When you write user stories in software development, you write the goals and reasons instead of the user. To do this correctly, you need to think like a user. You should understand the users and their intent. Before you start working on user stories, determine who are the real users of the software you are developing. Capture their profiles, their pain points, desires and expectations. Do not think like a developer or a project manager, instead, think as one of the users

5. Make success your goal

While all user stories should have acceptance criteria, do not set yourself up for the acceptance. Set up your user stories for success. "It works as intended" should not be enough for you. Think about the metrics that directly link to user feedback. Capture how happy, satisfied and engaged your users are with the new functionality.

6. Use tags and metadata

Usually, complex projects tend to have hundreds of user stories. To administrate them better, tag user stories. Do not change stories descriptions drastically after initial drafting, as it might confuse the team. Use metadata to track the status of user stories and monitor them easily.

7. Create stories for a single sprint

It is always better to write user stories for a single sprint. If the user story cannot be accomplished in one sprint, you should break it down in smaller ones. It will allow your team to complete a new functionality each time and also push out them more frequently.

Why companies started using stories rather than feature requirements

User stories in software development are all about the value the new functionalities create for the users. Feature requirements simply describe how the feature should work, which is not enough to create valuable software. The main difference between the feature requirements and user stories is the value.

When you write user stories, you tell a story about the user journey. How they make a specific action within their roles. It brings the value on the surface, why are we building the software and why are we adding this functionality. If the story does not emphasize the value that the functionality has for the user, then the story is useless.

How do companies use user stories in the software development process?

We talked about the importance of the user stories in software development and went through the process of writing it. But how do companies use them in the development process?

Here are some areas where the development team might use user stories:

Product design stage: Together with user journeys and interaction (process flows), user stories create a solid foundation for good UX and UI design.

Development team planning and estimation process: Companies use user stories for team planning and estimation process. As they are implementable and timely, the project manager can determine the needed developers for the project and create estimates.

Cration of development tasks: Project managers create and assign tasks based on user stories. From a good user story, the manager can clearly understand what tasks should be completed to mark the story done.

Creation of test cases: Every user case has acceptance criteria. Project managers use them for creating different test cases to ensure the successful completion of tasks.

Communication: User stories provide easy to apply the method for communication requirements, which makes the work of the Project manager and development team more efficient.

Can user stories replace documentation?

User stories are not a replacement for detailed documentation. Together with use cases, user stories are perfect for starting up the specs before the development team adds details. User stories can benefit the company in different ways. However, they cannot replace detailed documentation. In some cases, they can be a part of the documentation on an agreed level. But it is best not to merge them and have fully detailed documentation and user stories.

Have Questions?

Whether it's about this article or your next project, our experts are here to help.

Similar Blogs

View All

An illustration of two people with headphones and customer reviews with 5 stars. The banner reads: How to Deliver Exceptional Customer Service and Satisfaction.

Guides