Today, every team wants to switch to agile methodology of Agile programming, i.e. put the user in the center of the process planning during product development. We're finally building a product for end users, right? User stories are one of the basic tools that help teams remember about the user when defining a product and its functionality. There is a lot of talk about how to write them correctly.
When writing user stories, it often seems to us that we write them from the user's perspective. However, ultimately they are always distorted by our point of view and specialized knowledge. Often, these errors are interconnected and never end solely with one incorrect judgment.
That's why I want to discuss some of the most common and most common mistakes teams make when writing user stories .
1. User stories that are too broad, general
When user stories are too general, it's easy to ignore key information about the expected activity and need. If there are many "and" or "or" in user stories, this is an indication that they are too wide and you should consider rewriting them. There is also a great chance that the user- written story is really epic, but ... That's right.
2. User stories that are too good
When user stories are written too well, we start talking about how we intend to implement them. This removes user focus and leads to poor communication in the team.
3. No negotiable
User stories should not be a specific and accurate description of the function. Sometimes, the user story has been written in such a characteristic way that the team has difficulty implementing it correctly because there is an easier alternative. In such cases, the team should be willing to compromise on the approach itself, provided that it does not harm the value to be derived from the user.
4. Repetition of the user story in the acceptance criteria
Acceptance criteria allow you to describe the conditions that must be met for a story to be marked as completed. This provides feedback, assistance in team planning, and tracking their work. Thanks to this, the user story is more rich, precise and testable.
5. Having an undefined user
Mentioning the user's personality in each user story may seem frivolous, but on the other hand it can bring great value in terms of results. This is especially important if your product has more than one user. Of course, features tailored to different characters will be available. If you want your team to be more suited to the results you expect from them, they need to know who the end users are and what benefits they will get by introducing the given functionality.
6. Bad context
After some time, almost every user story looks the same, e.g. as a content manager, I want a text editor to be able to edit the content. All this tells the team that you want them to build a word processor and nothing more. If you've been writing some user stories for a long time , take a break and come back to them with a new perspective. Sometimes, even after a break, you may not be able to come up with something more meaningful. This is a good indicator that you should talk more to users and better understand their needs. There really is no need to reinvent the wheel.
Proposal
While using user stories can be useful, it's never as easy as it sounds. One mistake while writing often leads to a number of others as by-products. And then we will find ourselves in an even greater mess than if we did not write it at all . Therefore, if we decide to prepare it, let's devote a lot of time and attention to it.