User Stories and Acceptance Criteria: The Supporters of Software Quality

Today, when we think about software quality, we already imagine automation of functional/performance/integration/unit tests, but we must first note that there is no point in thinking about automation if we do not have well defined what will be tested. At this point comes the importance of creating stories and acceptance criteria in order to enable the correct implementation of test automation.

We must remember that the increase in software quality is not just at the end of the development flow, but permeates all phases of the process. As we can see in the figure below, the sooner the defect is found, the higher the speed and the lower the cost of correcting it.

Thus, when we think about software quality, we must start the work by correctly specifying the stories and acceptance criteria, which will be the basis for future quality processes in the development flow.

But, how to do this?

First let's talk about user stories (User stories)

User stories are representations of the features that the system must have, they are the foundation of software construction and must be written by the PO (product owner) with support from the application's stakeholders. The user story concept comes from XP (eXtreme Programming), its idea is to standardize and implement a simple and organized language for writing features.

What should a good story have?

In 2001, Connextra launched the story writing format:

As a?(role), I want (action) So that?(why).

Following this format in story writing, we must answer the three questions:

Who benefits? Stakeholder who benefits from the user story (Role). This information serves to detail the permissions for this feature.

What do you want? High-level view of functionality for the user (action). Here we will talk about the functionality itself.

What is the benefit? The business value the story provides (Why). This information is very useful in prioritizing the story.

A really cool and quick way to assess the quality of a story is to use the three C formula. We consider a well-written story when it meets the following characteristics:

Card: Not too big, fits on a card.

Conversation: Facilitates communication between the user and the squad, providing a common understanding of the functionality.

Confirmation: It has sufficient acceptance criteria to confirm the functionality.

Another widely used evaluation method is the I.N.V.E.S.T.

The story should be:

• Independent: Every user story must be independent of other stories.
• Negotiable: Remember every user story is just a user's wish, so you can consider it just a starting point. Therefore, it must be fully negotiable.
• Valuable: Must represent business value, always. No business value makes no sense to exist, it's that simple.
• Estimable: The team must be able to estimate it.
• Small: It should be small and thus reducing uncertainty and estimation difficulties.
• Testable: All user stories must be testable, that is, it must be possible to validate that they meet the acceptance criteria.

How to spot a bad story:

It is very common to observe the examples below, however, they should be avoided because they bring difficulty in the development of the functionality. We should note that stories should not be:

Too large: It is very common to see stories that are a grouping of many features, resulting in confusion and difficulties in developing and testing.

This story has many features grouped together, at least 3 stories of this create, change and consult.

Does not provide communication: The story is used as a functional document, serving as an excuse for not having communication between PO and DEV. User story does not replace team communication!

Very technical: The story is the representation of a customer need, in this way, we must talk about how this technical modification will bring benefits to the business, facilitating its prioritization and understanding. We shouldn't write history like:

We can write this same story while preserving the business vision:

Which of these would be easier to prioritize development? Obviously the second one, because here we can easily understand the benefit of its implementation.

No business value: The delivery of this story does not result in any value for the customer, we have to be careful when we disaggregate features of a story, so that it doesn't become meaningless in the business vision.

The change button cannot be delivered in production without the save button, so delivering this story has no value to the trader.

Acceptance criteria: The foundation of quality

The story can be very well written, however, if it does not have well-defined acceptance criteria, you can be sure that we will have problems in development. The acceptance criteria will define the behavior of the functionality to be developed, thus allowing all squad members to equalize understanding.

The acceptance criterion will determine which behavior must be observed after the development of a certain story, for it to be accepted. These are the famous test scenarios that the user wants to see executed after development is complete, in order to validate that the story has been implemented accordingly. Hence the name acceptance criteria.

Correct writing brings the following benefits:?

1. Provide material for the team to think about how a feature will be performed from the user's point of view.?

2. Eliminate ambiguities about requirements.?

3. Confirm the story is complete and working.?

4. Ensure greater user satisfaction.?

5. The scenarios that will be tested at the end are already known to the entire team from the beginning of the process.

It is important to understand that acceptance criteria are different from the D.O.D (Definition of Done)

D.O.D determines which activities must be performed in a given story to complete the story.

How to create a good acceptance criterion?

First we need to understand that the function of the criterion is to inform the expected behavior of a given story. In writing, we must exercise the different behaviors that can occur in positive and negative scenarios and in the usability of the story. We shouldn't be afraid to write a lot of acceptance criteria, as these will provide the much-needed detail to avoid problems in development.

In writing the acceptance criteria, we used the gherkin language and the BDD (Behavior Driven Development) technique, this practice leads the squad to think about the behavior of the system to understand what to do before writing any line of code.

For writing we will use the words Given, When is Then:

Given (Scenario precondition, at what point does it start)

When (Action being performed)

Then (Expected Result of Your Actions)

Let's analyze the following user story:

We must think, what are the expected behaviors that the functionality will have, not only the positive ones, but also, how it should behave in an error scenario. Well, it is as important to grant access to an allowed user as it is to deny access to a non-allowed user.

We should avoid detailing the scenario too much, as we are following the BDD and not the BDT (Test Driven Development). We need to focus on the behavior of the functionality.

Technical acceptance criteria can also be included by the technical leader or architect of the squad, validating development items, such as service creation or database modeling.

And last but not least, the acceptance criteria can be modified, added to, and removed over the course of the story's development cycle. Updating the acceptance criteria during the evolution of the story avoids possible “surprises” in the approval of the user.

Conclusion:

User stories and acceptance criteria are the basis of quality in the development cycle, they help us to understand the behavior of the application in order to anticipate possible defects that would only be found in the approval of the user. Anticipating problems, acting in the prevention of defects is better than staying up all night correcting a production error. Software quality is not just testing and automating, but acting in all steps of the software cycle, predicting and acting on the problem as quickly as possible! Writing history and acceptance criteria correctly is the secret to a squad's success!