How to Write User Stories for Software Development Team?

To build a great web app, try to put yourself in the shoes of a potential user. It is important to understand exactly how a user will interact with the product, how it will benefit him, what problems it will solve, what is really important and what is secondary. User stories, which are usually written at the start of a project, will help to develop client-oriented software and to avoid overpayment for extra functionality.

User story: what is it?

There are several definitions of the term "user story". They can focus on different aspects. But one of the most precise is:

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

It’s a very simple definition. But it lets us see that in the center of a user story should be a person (a user) and this person’s need. A user story should let the developers see the context and the value of each feature for the client.

A user story describes the type of user, what this user wants, and why. It helps to create a simplified description of a requirement. So it’s better to avoid using difficult technical terms in writing a user story. It should be as clear as possible for all stakeholders. It is important because a user story – it’s a starting point. It has to go through the stage of discussion in order to find the best ways to achieve the goal and satisfy the user’s needs. In other words, the user stories should be written in the language of the customer and be totally clear for developers.

Why do we need user stories?

Have you ever found yourself in a situation, when you can’t explain to technical guys what exactly you want to get as a result of your cooperation? How to be sure, that you’ll move in one direction and your idea will be implemented properly?

User stories can be really helpful. Thanks to these small notes, you can outline your goal and to make it clear for each participant of a dev process.

Let’s define the main advantages that user stories will bring to cooperation between customers and developers.

1. User-focusing. User stories make us think not about an abstract task, but about the real needs of real users.
2. Teamwork. User stories require discussion in a team for finding the best ways for solving the problem.
3. Time-saving. Can save time when prioritizing the development. Our priorities are already formulated in our user story.
4. Best results. Working with user stories helps to see the business value and to deliver products that end users actually need.

How and when to write user stories?

Usually, a story-writing workshop is held near the start of the agile project. The goal is to create a product backlog that fully describes the functionality to be added over the course of the project.

A user story has its classic template: Who – What – Why. It is used, as a rule, because it is comfortable.

Mike Cohn, one of the founders of the Agile Alliance and Scrum Alliance, writes, that the optimal way of writing user stories is in the form of: As a - I want - so that.

For example:

As a user, I want to upload photos so that I can share photos with other users.

As a user, I want to be able to cancel my reservation at any time so that I do not lose my money if an accident occurs.

As a manager, I want to assign roles to a user so that I can control the user's access to the system.

As a manager, I want to edit any information in the system so that I can be sure that all information is up-to-date.

Mike Cohn gives us few reasons why this form is the best in his opinion. And the first reason is: when requirements are put in the first person, it works like a magic. You start thinking as this person, as a customer. And it is very important for understanding customer’s real needs.

It is the most used form. It gives a clear structure for a user story and helps to define when the work is done.

In our team, we specify some additional info in user stories.

Our team agreed to use three additional rows in the user story table: Assumption, Rating and Complexity. It helps not just to define the feature, but also to outline the way it will work in the end result. A rating system is used to designate the priority and importance of each requirement and also its complexity. So we can provide rough estimates for each feature, we describe in user stories.

And it’s important not just for the developers. For example, in order to stay within the project budget, the client can estimate how critical each feature is in combination with the complexity of its development. And to make a decision about the importance of this or that functionality.

What are the indicators of a proper user story?

Great user stories always fit the INVEST set of criteria by Bill Wake:

• Independent – they can be developed in any sequence, and changes to one user story don’t affect the others.
• Negotiable – it’s up to the team to decide how to implement them; there is no rigidly fixed workflow.
• Valuable – each User Story delivers a detached unit of value to end users.
• Estimable – it’s quite easy to guess how much time the development of a User Story will take.
• Small – it should go through the whole cycle (designing, coding, testing) during one sprint.
• Testable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately.

It’s better to omit using such a role as simply "the user". It can be applied to any person and, therefore, it doesn’t reflect the personality of particular target groups, the way they interact with the application. Give your user (user persona) a name. Think of his mobile habits, what issue your app is going to get resolved for him, and how you’re going to make this path easier and faster. Remember some people who you know from real life and who fit this portrait; feel how you relate to this target group. In this case, you’ll have really great results!

Where does a user story lead to?

User stories lead to the satisfaction of the user's needs. Also they help to reduce costs of software development and to avoid waste for extra functionality.

But that’s not all. A user story is a small tool in Agile software development. It’s a part of an epic. In agile development, an epic, it’s a series of user stories that share a broader strategic objective. When several epics themselves share a common goal, they are grouped together under a still-broader business objective, called a theme. To put it simply, a user story is a one-day sprint, a step to the realization of a big project.

When we talk about user stories, we should consider that they are the elements of Agile methodology. The Agile is a way to manage a project by breaking it up into several phases. It involves constant collaboration with stakeholders and continuous improvement at every stage.

The adherents of agile development claim: there are several benefits of breaking a team’s development work down into epics and stories:

• allows making more strategically sound decisions
• improves performance monitoring and timeline estimates
• keeps the team focused on the key goals

So, by working on small user stories, you are moving forward to your Big Goal.