The user history (or user story) is a formal explanation, within an agile context, of a requirement. It can also be considered a functional requirement of the project, if we use a more classical language. It is, in short, the place where the expected behavior of our software will be expressed, which will not only serve as a guide to understand what our product does and does not do, but will also be the artifact that will allow the team to work on the agreed specifications.

How to create user stories?

User stories are divided into three parts: card, conversation and confirmation.

Card

It is a sentence with the following format:

As [type of user] I want [need] for [expected benefit].

This defines the three fundamental aspects of a HU:

• User type: ensures that we have identified all the types of users that affect the project. For example, the user type could be the customer, the platform administrator, premium users, etc., etc. This responds to the «for whom».
• Necessity: it assures us the fact of having defined what we intend to develop this functionality. This responds to the «what».
• Expected benefit: it assures us of the fact that this story brings a concrete value to the defined user. Here we detail what the final objective of this development is. This answers the «why».

Conversation

The conversation is a face-to-face discussion with the person who created the user story (Product Owner, Product Manager, etc). In this conversation we are looking for the following:

• Have the entire team (developers, designers, PM/PO, etc) understand the user story and its objectives. The idea is to keep the conversation going until everyone is clear on what is being sought, for whom and why.
• That the people who will work to develop the story are clear about the tasks they will have to create to achieve it.
• That the team that is going to work on it can estimate its difficulty (either in time or in effort points).

The importance of this discussion lies in the fact that user stories should not be a mandate from project management or the client, but a request for a need whose solution (how we will address it) comes from the entire team.

During this conversation, the team will understand what is intended, agree on how to get there and, finally, reach a compromise on the cost of doing it, either in effort points or in time. In addition, at that moment or a little later, the people in charge of developing each user story will have to create for themselves the tasks required for that task (we will talk about this later), and associate them to the relevant user story.

Confirmation

Also called Acceptance criteria. This is the behavioral agreement of what we are going to try to build. They are the conditions that the user story must fulfill for its development to be correctly completed. They have a binary behavior: either they are fulfilled or they are not fulfilled, there are no intermediate states.

Examples of classic confirmation criteria that can accompany a user story (in Secture we don't work exactly like this, I explain it below):

• Dada a search for the user in the home page, when presses the enter button on your keyboard, then you will be forwarded to the results page.
• Dado that the user has clicked the buy button and reached the confirm purchase page, when choose PayPal as your payment method, then we forward you to the PayPal payment gateway.

We, at Secture, do not use the classical method, since, in general terms, they become more complex to understand and, above all, to cohere with each other. We use a language called Gherkin, that helps us to have the expected behavior structured, in a way that is understood by customers, PMs, developers, testers, etc. We will write, not too long from now, another article explaining Gherkin.

INVEST Model

A good habit when creating our user stories is to make sure that they comply with the INVEST model. This model provides us with clues as to what an effective user story should look like, and is based on six aspects that we will see below:

• Independent: the story should not depend on other tasks or stories in order to be completed. Specifically, they should not depend on future stories, although they can depend on stories that have already been completed.
• NNegotiable: it must have been negotiated and clarified between the client and the team.
• Valor: it must add value to the project.
• Eestimable: the team must be able to estimate the effort required for its realization. If it is not estimable, the story must be rethought.
• Small (small): it should be small enough to fit in the sprint and, if possible, be done in a few days or one.
• Tstable: it must provide sufficient data to measure whether, after its implementation, it meets the objectives set.

When can a user story per list be given to calendarize?

In agile projects there is usually a document (artifact) called Definition of Ready (also known as DoR). This document contains those obligations or characteristics that a user story must meet before it can be introduced in a sprint. That is, it is a formalization of what criteria we have to meet before scheduling our user story and the team faces its development.

The DoR is not an immutable element. As the project progresses, we will discover that it is desirable to change, remove or add features. Experience and, above all, setbacks, will give us a better perspective on the content of this document. An example of some of the obligations to be fulfilled in a DoR could be:

• The story must be written exactly in the ‘user story’ format.
• The team should confirm that they understand the acceptance criteria and the objectives of the story.
• The team has estimated the effort of the story.
• The PO has established the business value of the story.
• The story follows the INVEST model.

Is it possible to have more than one Definition of Ready in a project? Yes, there can be several, depending on the user's history and needs.

When can a user story be terminated?

In agile projects, there is usually a document called Definition of Done (also known as DoD). When a user story meets all the requirements of the user story, it can be considered as finalized and ready to be uploaded to production or a pre-production environment. The content of this document (or documents, (because there may be several depending on the type of user story or tasks in the sprints) differs from one project to another and there is no standard as such. What we have to be clear about is that it must be formalized here what requirements we have had to fulfill for a user story to be considered finished.

Having this document allows us to unify criteria and avoid disputes or misunderstandings within the team once development has begun. If everyone is clear about what has to be fulfilled, we facilitate many aspects of the project.

A very basic example of aspects that a DoD could have would be the following items or obligations:

• Completed user history related tasks.
• All story acceptance criteria are met.
• The code has been reviewed by two different developers.
• The associated code has been put into pre-production environments without compilation errors.
• Unit tests have been performed and passed.
• Functional tests have been performed and passed.
• Customer approved feature.
• Feature approved by the UX expert.

Obviously, this DoD could have many more points. Moreover, as we mentioned before, we may need different DoD depending on the type of task. A user story is not the same as a Spike (R&D within a sprint), for example.

How to prioritize stories?

User stories are the basis of any project since they are the reflection of the final behavior that our development must comply with. When we have a group of user stories and we put these ideas in the product backlog waiting for the right time to include them in a sprint, how do we order the stories to decide when to address each one? There are many techniques that allow us to assign priorities, since it has been highly demonstrated that doing it by eye is not functional if effective. For this reason, I invite you to read the following article where we discuss four prioritization techniques that work very well in projects.

Estimates of user stories

When are they estimated?

The stories should be considered always. You can measure based on two concepts:

• History points (score of the effort required).
• Time in hours: number of hours it will take to complete the user story.

In both cases, they are evaluated on the basis of several factors:

• User story complexity.
• Amount of work.
• Risks and uncertainties.
• Technical capacity of the team for its resolution.

In addition, the user story can be estimated either in itself or through the sum of effort required by the tasks that compose it.

In the case of history points, these will be used to measure the speed of our team in the sprints (velocity). If our team is able to assume, for example, twenty story points on average in each sprint, we will say that the speed of our team is 20.

When are they estimated?

Always after finishing the three Cs (Card, Conversation, Confirmation). In addition, a user story cannot be started or scheduled (sprint) without having been estimated.

How are they estimated?

There are several techniques that allow us to estimate user stories. Two of the most widespread are covered in the following article.

Are user stories and tasks the same thing?

Normally, tasks are children of a user story. Taking into account that the user story tells us how the application behaves from a functional point of view, the team needs to create specific tasks to achieve that end. For example, a user story may be about how the login works, but then the developer and designer will need to create their own tasks to fulfill the use cases, such as designing the login screen, creating fields in the database, creating the business logic, etc, etc, etc.

Therefore, a user story has several tasks under its mantle. And these tasks are created by those who are going to work with it, i.e. the team that develops the solution.

Anyway, if you want to go deeper into the type of tasks that exist in an agile project, you can see this other one article where we talk exclusively about it.

Conclusions

User stories or user story are a capital artifact in agile projects. They are not only the substitutes for the classic functional requirements, but also, well done, they are the documentation of the project from the functional point of view. We must take care of them because they are the main axis of the different developments and their good use can be the difference between an orderly development, with criteria and quality, and one that stands out for the opposite, with all the damage that this entails.