User Story … What is it?

I am an apprentice and I need to write a small blog for my work, right now.

The last sentence is an example of a user story, but what is a user story?

When you want to collect requirements to start a project, you should start a small conversation with your client, in this talk, you should ask him what he wants from the project, what his expectations are and what he wants. The answers will probably be user stories.

The user stories are very short and schematic descriptions, which summarize the specific need of a user when using a product or service, as well as the solution that satisfies. Its main function is to identify perceived problems, propose solutions and estimate the effort that identifies the proposed ideas.

Usually, when you write this sentences, you must specify its title, function, priority, estimate of the time required and, finally, the acceptance criteria, the latter is really important because it is the basis of QA to do your job well.

You can use this template:

A good user story should be:

• “I” ndependent (of all others)
• “N” egotiable (not a specific contract for features)
• “V” aluable (or vertical)
• “E” stimable (to a good approximation)
• “S” mall (so as to fit within an iteration)
• “T” estable (in principle, even if there isn’t a test for it yet)

The collection of requirements and tests in the development of agile software depends largely on the stories of the users, so if we make mistakes when defining them, we can have problems throughout the development.

You can think about how to make mistakes when expressing requirements in such a simple way, however, this simplicity can cause problems. Of course, writing good user stories will be more difficult for novice teams in agile methodologies.

The mistakes made when writing the stories can cause a misunderstanding of the requirements, a poor formulation of the test cases and, worse still, a poor implementation, which causes the rejection of the results of an iteration.

In Pernix we use agile methodologies, however, we do not give importance to user stories, because it is believed that they take time away from development, when the truth is not so. As I mentioned, these little stories provide a complete vision of the system to be developed and, therefore, the requirements become clear and easy to understand.

Sometimes it is better to spend a little time at the beginning of the project when collecting user stories and writing the requirements as they should, because we do not want that in development, we have many things that need to be restructured, because we simply omit or we misunderstand the information.