What are user stories and how to use them when developing a web or mobile app from scratch?

When a business comes to an IT company and requests to develop a web or mobile apps, in most cases, businessmen only have an overall vision of the product that they want. But the development team can’t bring the client’s idea to life with this vision only. If the functionality is vague, the development will go beyond the planned time and budget. How to define product requirements and get the result that will match the business needs? User stories can help.

This article is about user stories, an analytical tool that we use in Ronas IT. We’d like to advise this tool to other teams that develop solutions for businesses using agile-based development. In this article, we’ll tell about user stories, why one should use them, and how to write useful user stories.

Ronas IT is a company that creates digital solutions for small businesses and startups. Our work approach is based on business analytics and agile-based development. We have already been on the market for several years and helped our clients to launch some successful projects in the fields of fintech, team management, business automation, and delivery.

What are user stories? User stories are a form of describing the product requirements. They use informal language without complicated technical terms. Each user story consists of three main components: a type of user, an action that this user takes, and a goal that the user has. Usually, user stories look like this:

• As a type of user - as a client of an online store
• I want to take an action - compare various products
• To achieve a goal - find new information about the products

User stories are aimed at answering three questions: who acts, what action the user takes, and why he or she is doing it. These questions help to define the types of users, app functions, and problems that the app will help to resolve. And all this - with the use of language clear for everyone. User stories were invented to ease up communication between project participants: clients, designers, developers, and stakeholders. User stories help the development team to understand who will use the app, how they will use the app, and why they need to use it.

User stories appeared when agile-based development became popular in the IT industry. The agile approach helps to minimize possible risks that may emerge during the development process. For example, it can prevent a situation when the client’s expectations don’t match the real app functionality. Or a situation when users don’t understand what conveniences and benefits the app brings. If this happens after MVP’s launch on the market, it will be expensive to fix the mistakes. When the development team has the user stories, it is easy for the business to track the development process. With user stories, the project is divided into small, comprehensible bits that the business can check and change if needed.

User stories aren’t a development tool. Even though they describe product requirements, they can’t be used for writing code. User stories are an analytical tool, which connects the worlds of business and development.

User stories as an analytical tool. When creating a new product, analytics is a stage of describing it. Analytics helps to understand what business goals the app will fulfill and what benefits users will get by using it. User stories match the analytical objectives better than anything else because they help to understand who and how will use the product, and what their aims will be.

User stories do not describe the material appearance of the app. They are user-centered and can be easily modified. Let’s explore the advantages of user stories more thoroughly.

Stories are not linked to material appearance. The main advantage of the user stories is that they don’t restrict professionals when they work to achieve a business goal. An experienced developer or designer knows how to bring the product idea to life. Professionals will find the best way to provide a convenient user experience, arrange screens, and make transitions.

Stories are user-centered so they guarantee that a developed product will be useful and that it will solve real problems. A digital product is something users interact with directly. Users will be more willing to purchase a product if it is convenient, understandable, and fulfills the user’s needs.

Stories can be modified. Products that are just being launched on the market to test the business ideas may need an opportunity to change and adapt. User stories make clear what features are convenient and what are not. For businessmen, it is easier to understand informal story language rather than complicated SRS full of technical terms. Functions described in the story are easier to track and correct.

How to create useful user stories. To test user stories, we use the INVEST principle. This is an abbreviation that includes the first letters of 6 main user stories parameters.

• Independent - each story doesn’t depend on other stories and can be used individually.
• Negotiable - stories can be changed.
• Valuable - stories yield benefits for clients and businesses.
• Estimable - we can estimate the implementation of a story.
• Small - story is the smallest part of a project that describes a single action.
• Testable - the implementation of the story can be tested.

We don’t have to check if each story matches all these parameters, but it’s better to take them into account. Using these parameters, an analyst can create stories useful for the client and the project team.

How we use user stories in Ronas IT. Our team uses user stories at every stage of the project work: in analytics, design, and development. This approach helps to keep the clear vision of the project during the entire work process without functionality blurring.

There are two reasons why we create users stories at the stage of analytics: to provide our client with a clear vision of the project and to prepare a project estimate.

Users stories that answer questions “Who?”, “How?” and “What for?” provide a full picture of the future product. Using them, we can prioritize app or website functions for the development. With prioritizing, businesses can launch an MVP to the market to test it on real users, then collect their feedback and continue developing it.

Our analyst discusses the project with the client and then creates a list of user stories. The analyst discusses business aims that the product fulfills and the target audience. Then he or she breaks down the aims into tasks to be performed. After this, the analyst researches rival businesses, finds already existing solutions and describes the functionality of the product. As a result, the analyst creates a list of user stories that he or she puts on the map to outline inner connections in the app. For this, we use visualization tools like in the illustration below.

Implementing user stories, we can also create an estimate. User stories are different from SRS or screen-by-screen app descriptions because they are not linked to material form. With user stories, designers and developers can find the optimal way to bring business ideas to life.

If you describe an app screen-by-screen or button-per-button, it is easy to skip some steps of interacting with the product. To take into account all the possible actions and transitions between screens or pages, you need to think about it as if you were a user. Analytics and user stories help our clients with that.

The project team uses the created list of user stories to plan sprints for the next stages of work, design and development. The user stories lay the basis for the clear dialog between the project team and their client. During the work process, our clients can check the outlined plan and edit it. This approach makes the process of product development transparent and controllable.

We create this article to give our readers a perspective on how to use user stories when developing their products. If you want to discuss your idea with us, click here.

Let’s summarize!

• User stories are a form of describing the requirements for a digital product.
• User stories help clients and project teams to better understand each other.
• User stories are a tool of analytics, not development. It’s important to implement them in the project as early as possible.
• An estimate based on user stories is more accurate than an estimate based on SRS or screen-by-screen functionality description.
• User stories help to plan and prioritize tasks for design and development.