How to Write User Stories and Why They are Crucial for Successful App & Software Development

If you want to develop a mobile or web application, User Stories will help you to find common ground with a development team, especially if you don’t have programming skills and don’t know the technical language. We can say that thanks to User Stories, our work implementation is better prepared, and in some cases, the development can be faster.

In short, User Stories:

✔️ eliminate bridges between business and technical teams,
✔️ help with product understanding,
✔️ engage app users in process modelling.

But, how can we achieve this level and use all of these advantages?

In this article, we will try to answer that question and explain to you why using User Stories are so efficient and valuable from a business point of view.

What exactly is a User Story?

A User Story is a description of an application’s functionality and it should be understandable for everyone involved in the product development process – for both developers and non-technical team members.

A User Story usually consists of a Summary and a Description. In this article, we will focus on the Summary because it’s the crucial part of the User Story, which is mostly underestimated and difficult to formulate.

? Read: How to Build a Minimum Viable Product – MVP Guide for App Owners

6 attributes of a good User Story

A good User Story can be described via six attributes (INVEST by Bill Wake):

• Independent – this means that we should avoid dependencies between User Stories as much as possible. It is better to create a bigger story than one with dependencies, which can cause problems with estimation and prioritization.
• Negotiable – stories are not fixed descriptions of functionalities and they should contain in their description only short information about the basic specifications. If more information is required, a development team should start a discussion with the Product Owner.
• Valuable – stories have to be valued by users of the software or the Product Owner (client). Thanks to this direction, the Product Owner can easily handle prioritization and scheduling.
• Estimatable – in most cases, a User Story is not estimable when it is too big, not described well or developers have not enough knowledge to do it. In all these cases, the team should resolve the problem and try to make the story ready for estimation.
• Small – the proper size of a User Story is based on the team, its knowledge, the technologies being used, and the project type.
• Testable – stories should be defined as a testable part of a working system, if a story has passed its tests, it proves that it has been successfully developed.

To achieve all of these points, the whole team should work together and discuss each User Story on Refinement meetings during Sprints.

Thanks to this approach, the scope of the project will be clear for everyone which, for sure, is going to have an impact on the quality of the development process.

User Story template

It’s clearly visible who is an actor, how does he interact with the system’s component(s) and why or where does the interaction take place. Using this pattern and remembering these three elements allows us to write simple and understandable stories every time and usually for each case. 

? Test yourself ? Which User Story is correct?

We already know the rules and we know what kind of criteria a good User Story should follow. So, have a look at two examples of how good and bad User Stories look like.

Let’s say we would like to write a perfect User Story using an example of Instagram.

Instagram User Story // Example 1:

Try to guess which of these two options would be better:
User’s personal data can be edited by a user or User edits his or her profile to update their personal data

At a glance, the first story seems to be good enough. But, do we know Why / For what / From where the action of editing data has to be available on Instagram? Remember that, sometimes, it’s obvious for an author, though we can’t be sure that someone who will work on it will understand it as well.

So, let’s see why, in this version, when a User edits his or her profile to update their personal data, it is better. We know who (user) is doing, what (edits his profile), and why (to update his personal data).

Instagram User Story // Example 2

We can start with a story where the App should let users add stories. Do you see which parts of a good User Story pattern are missing here?

How should the correct version look like? Let’s compare it with the example when a User adds stories to his profile from the profile tab to show it to his friends.

The table shows which parts are missing in the first User Story. Without Who and Why / For what / From where , the action is completely unintelligible. 

Based on these two comparisons, we can learn how to recognize a good pattern, which will help our teams build a product matching a Product Owner expectations.

8 great advantages of User Stories for your business

Mike Cohn wrote about 8 great advantages of User Stories in his book, which perfectly shows why they are valuable for business:

1. User Stories emphasize verbal communication – instead of writing an extremely detailed description or documentation for each requirement, the Product Owner should be in contact with the development team. The User Stories form forces both sides to communicate and make the feedback loop as short as possible. Only in this way will you get what you want; in the opposite case, it will probably only be the developer’s interpretation of the written document. Get our Free Guide for Product Owners – Drive your Product to Success.
2. User Stories are comprehensible to everyone – the opposite to detailed technical requirements, a good User Story is clear for developers and business people, which helps in implementing the right software.
3. User Stories are the right size for planning – release planning, risk forecasting, and prioritization are clear processes when the requirements are the right size and not too closely combined with other parts of the software, both for developers and client.
4. User Stories work for iterative development – there is no need to have completed list of User Stories at the beginning of the project. The team can start with a few of them and add new ones during the development process through the next Refinement meetings. This advantage especially supports products which are not well known at the beginning and will be changed often during development.
5. User Stories encourage deferring detail – stories can be written during the whole project, so you, as a Product Owner, can add a bigger epic whenever you want and then, in cooperation with the developers, you can easily describe or split it later.
6. User Stories support opportunistic design – software must be developed opportunistically, because most of the time our product changes during the implementation process and we are incapable of remembering that many details and predicting all the possible problems or dependencies.
7. User Stories encourage participatory design – User Stories help to engage real users in the process and it allows you to react quickly to their needs or expectations.
8. User Stories build up tacit knowledge – the knowledge builds up within the team, not just the Product Owner.

Experience shows us that the most important part of the mobile application development process is a good understanding of customer needs and real values, which stand behind ideas that have to be implemented.

This is only possible when developers and the Product Owner use the same method to describe software functionalities and, as I wrote above, User Stories make this happen.

• Read also: What is Product Discovery in mobile application development

Wrap up

User Stories are universal and we can use them in any kind of projects, including mobile & web application development processes. Properly prepared, they can be a big help for the team and the Product Owners.

If you want to go deeper in the topic, we strongly recommend you Mike Cohn’s book “User Stories Applied”, which is full of example cases, explanations and good conclusions about User Stories.

Now is the time to check your new knowledge in real life ?

Let us know if you have any other ideas when it comes to creating a good User Story. Just leave us a comment on the article.

Related posts