The main purpose of every application is to satisfy customer needs. If you know the customers' end goals that they’re aiming to use the application for, it will be easier to determine the right set of functions that needs to be included. An app that caters to the user’s needs perfectly – isn’t that a Holy Grail for every developer? Creating a truly worthy product without having to commit numerous shots in the dark – how does that sound? Here’s what we have to say about what user stories are, how to write them and what to watch out for while doing it.

An Introduction to User Stories

User stories are used in development for a better understanding of what functionality is likely to be required. User stories aren’t equal to technical requirements; rather, they are short descriptions of a particular functionality, which is derived from the user's goals. There’s a popular opinion that user stories can actually be the main tool for any analytics and project managers: it helps them provide a simple explanation for the developers indicating what should be done and why.

At Exyte, we use Agile and actively utilize user stories to achieve a deeper understanding of how our customers' products benefit their end-users. They also foster collaboration and creativity by pushing us towards non-trivial solutions in the development process. The ultimate goal is to achieve a common image of what we're trying to accomplish and how we're going to do it within the team involved and users targeted.

A common formula for the user story is As a < type of user >, I want < some goal > so that < some reason >.

As "a description of a customer portrait"

I want "to be able to do/to do something"

To "get the desired result/benefit"

At first glance, the formula seems very clear. Let’s take a look at the following example:

• As a user of a food delivery app
• I want to be able to order dinner
• To save time on going to a restaurant and having a delicious meal.

Some nuances need to be taken into consideration. Let’s look at the next example: As a website owner, I want to add a red button to increase conversions.

• What's the mistake?
• Where does the button go? Why is it red and not blue?
• "To increase conversions" is not a description of the desired result. To make it possible to digitize and test the result, it would be better to rephrase it as "Add a button leading to the cart with the option to pay".
• Where exactly on the site do they want to add a button?

These are just a few nuances that can mess up your user story or jeopardize the clarity of the results.

The process of creating

According to world-famous agile coach Mike Cohn, user stories are not the final requirements for the system, and are not meant to be useful at the end of an iteration. User stories are important for finding out exactly what the customer longs for. User stories can be used to identify a user's major needs and possible ways to cater to them with your product.

User stories are lined up in a specific workflow: Analyze, Develop, Test, Done. Where to start? 1)Create the images of your users – who your potential customers are, what their pains, problems and needs could be, and how your product would help them. At this point, it's worth conducting a series of interviews to get a better understanding of the customer. 2)Creating an epic. An epic is a large block of tasks that can be broken down into several smaller stories. Writing epics helps you identify the key features of your product without going into too much detail. 3)Breaking down an epic into user stories for those involved in its implementation. 4)Prescribe the acceptance criteria.

Some important points to consider:

Larger stories work best when they are broken down into smaller ones that can be more easily and quickly tested in practice. Each story must have a Definition of Done and a readiness criterion by which you can tell that the requirement has been met. This is required:

• To avoid getting bogged down in an endless development cycle and to understand when a story is complete;
• To understand what the team needs to do before getting to work ;
• To achieve a common understanding of the customer's need;
• To validate the story with the help of testing.

To validate the task, the agile team conducts a demonstration of the new functionality to the customer, gathers the comments, and thus gets prompt feedback.

Examples of DoD:

• Tests are successfully passed;
• Compatibility with the previous API versions is ensured;
• Code review is completed;
• A user story is approved by the customer.

Checking user stories

You can check user stories using the INVEST approach:

I (Independent) – your story does not depend on the implementation of other stories. For example, can the team finish the task without any help from other teams, not having to wait until they have completed their scope of work?

N (Negotiable) – you have already discussed the story a few times.

V (Valuable) – once implemented, the story will bring real business value.

E (Estimable) – you can estimate the amount of labor resources that is necessary.

S (Small) – the story can be implemented in one iteration.

T (Testable) – there are clear acceptance criteria and test scenarios for checking the results in practice. This way you can check both the successful track and the conditions that have caused errors.

What to consider

• There is no reason to be afraid of changing your story. Even if you spent years on its creation if the conditions have suddenly changed, your story must change, too.
• A user story is not equal to technical requirements, it is a minor scenario that includes a set of user actions. Therefore, it should be described in simple words, clear enough for everyone to understand.
• There should be a story for each user profile in your audience, each of which needs to be verified.
• Split large stories into smaller ones, as this way it’s easier, faster and cheaper to test them in practice.
• It’s best to update the backlog after each iteration.
• Your sprint should consist entirely of tasks aimed at implementing user stories. Set aside enough time for bug fixes and technical debt so you don’t end up piling up your problems.

Something important:

Creating a great UX (user experience) requires more than using solely stories. Stories help define the functionality of a product, but they are not sufficient for depicting the User Journey and preparing the visual design. So it’s always best to complement stories with other techniques: story maps, diagrams, storyboards, sketches, layouts.

A user story seems to be a daunting task when you really look into it. Indeed, it is: not only do you need to know your users perfectly well and know their needs by heart, but you also have to pay extra attention to digitizing your results and tests. Writing and working through the stories will require a large amount of your time and concentration. However, if you cope with these challenges, you will be definitely rewarded with positive feedback from customers, who "got the job done" with your product.