User stories are probably the most common technique in Agile to list functions or product errors. Apparently easy to define, in fact can cause many misunderstandings if they are not properly identified and told. There are a lot tips and rules for creating stories. But is there an ideal method? You will find out below. I also encourage you to read this article if you use other techniques to define tasks for the team on the daily basis.

The format of your paper cartons

There are many tips for creating good user stories. One of them is the principle that stories should be in line with features described using INVEST acronyms (William Wake, author of Extreme Programming Language and Refactoring Workbook who used acronymes for the first time). Often used template is “As <user type> want <task name> to achieve <target>”. The above tips and many others come down to the fact that many Product Managers are focused solely on creating a story that is consistent with the rules, which often leads to many misunderstandings. Some even argue that the business value of a story should be the most important, others, for example, that „I want” to be at the beginning. So I go against all these people and emphasize: Do not always worry about the format of your stories!

There are several reasons why you should not worry about the structure of the storyline until you have included all the key elements listed below:

• From the way you write down the story, it’s much more important to talk to the team whose “task card” should remind you of it. While the information in the story is true, every format is a good starting point for discussion.
• There is no clear evidence that the choice of a particular story-making policy over another will improve the team’s performance significantly. Also keep in mind that all tips / policies may not necessarily be up to you.

Templates are just a standard that may look different in your project. While using the “As <user type” want <task name> to achieve <target> “is a good way to start discussion, do not stick to a particular template regardless of circumstances. Otherwise, you might end up with a story like “As a system, I want a report …”. Instead of unsuccessfully pondering on fit into a template, verify whether the people are actually stakeholders and whether they do want what was just defined.

Experiment

I encourage you to experiment with your user stories. The following steps can be used as a help:

• Create stories at the beginning, but add all the details later (for example, during recurring meetings with the team which you will use to discuss future tasks).
• Do not write obvious solutions and thoughts
• Think of a larger number of stakeholders who may be interested in the function – consider whether it is not worthwhile to divide the story into smaller parts.
• Use pictures instead of words
• Ask questions

Using different formats can be a great way to spur a discussion with your team or look at a task from a different perspective. In many cases you will also avoid false stories. Alternatively, you can use an entirely different description of the requirements, such as use cases. This technique will help you more in the case of a precise description, for example, by adding preconditions and exceptions. Use Case’y will also work better if you do not have the ability to engage the team (example: for remote work) in the discussion or in the definition process.

A good way to move around the discussion is to write  down questions, not solutions. Focus on the problem, mimic the user instead of reflecting on the physical implementation.

Summary

Tips and templates are extremely helpful in defining tasks. Remember, however, not to follow blindly in one direction because it can give the opposite effect to the intended one. Experiment with different templates, think over the questions instead of solutions, and most importantly – talk. With these simple tips, your work will be much more efficient and will help you avoid many misunderstandings!