User Story Acceptance Criteria Given When Then Examples

Acceptance Criteria for User Stories

One of the main steps in software development is to clearly define the purpose of the product or service being delivered to the market. From both the end user and the development team perspective, the requirements for a particular solution should be met in the same way. This means that project teams must eliminate any misconceptions that users may have about how the product works and what it offers. Here, by writing clear product acceptance criteria, we will understand what conditions a particular user story should satisfy. As a result, the new solution will meet the needs of business, market and customers.

In this article, we would like you to better understand the meaning of writing a concise user acceptance criteria. Answering the basic questions that often arise when documenting the project requirements, we will also discuss what types and structures of software acceptance criteria exist. After that, we'll reinforce your knowledge with a few examples of how and when to write acceptance criteria to achieve more success.

So, let's make the main specifics clear for you.

What is an Acceptance Criteria?

The role of the development team in the development of a software solution is to ensure that each new feature meets the essential requirements of the business, customers, and product users. Once these expectations have been identified, it is important to write the appropriate acceptance criteria for user stories. But, what exactly does that mean?

Acceptance criteria is a list of conditions or requirements that the product should meet, to be accepted by users, customers, and other systems. Standard acceptance criteria could include an overall user experience and user story based on the main  features, key performance metrics, like speed, and what the user story should do. In other words, it defines the behavior for each specific feature based on a unique scenario in the user story. To make it simple, let's look at the graphic below:

Let's break this aspect down by explaining the correct user acceptance criteria and what benefits you can expect:

1. A common understanding of the requirements;

A problem is no longer a problem when everyone comes to a consensus on a proposed solution and is satisfied with the results they get in the end.

2. Smooth communication between the client and development team;

In the process of defining acceptance criteria, your team begins to understand what conditions must be met, and the client knows exactly what to expect. This significant step removes any misunderstandings between the development team and the client and makes communication more effective.

3. Correct user story planning;

To understand how to create a user story correctly, start working on defining the software acceptance criteria. From the users' perspective, all expectations will be fully met, as possible scenarios are foreseen and individual user stories are completed by the time users start using the product. In addition, the user acceptance criteria defines the boundaries for a user story. This way the team can better understand the functionality needed for the application. Based on the details provided, they can understand if the story is finished and works as required.

4. Accurate feature estimation;

Because your team understands exactly what needs to be implemented, user stories can be divided into tasks for more accurate assessment.

5. Simpler tasks for the development team;

The more detailed your user acceptance criteria is, the better you will understand what features are required. Plus, the development team will know exactly how to build this functionality to be successfully accepted by users and meet the standards they deserve.

6. Improved acceptance testing.

Serving as the basis of the testing process, each acceptance criterion can be separately tested to check if the scenarios are positive or negative.

As you can see, having the right acceptance criteria for user stories will ultimately help solve many problems, including reducing the number of unexpected bugs and errors in the final product testing phase.

Acceptance Criteria Types and Structures

Writing acceptance criteria based on the entry requirements can sometimes be challenging. This is why, in the software development industry, there are several types of acceptance criteria to simplify this process. The most popular are:

1. Scenario-oriented (in the form of scenarios that illustrate acceptance criteria);

The structure of this type is specific and commonly practiced when writing acceptance criteria in Agile. When using a scenario-oriented approach, the most common template is given in the form of:

Given (Some precondition)/When (I do some action)/Then (I expect some result).

This approach is convenient for most teams, because it is similar to cause-and-effect logic. This scenario form has been inherited from behavior-driven development (BDD) and illustrates each criterion separately. Thanks to its consistent structure, it is easier to define when to begin end testing of a feature. This format also helps to reduce the time spent on writing test cases, since all the requirements of the specification are met, and the systems' behavior has already been described.

 Here, you can see the key statements of the acceptance criteria template related to a scenario-oriented format:

Example:

User story: As a user, I want the system to recover the password so that I will be able to access my account in case I forgot my password.

• Scenario: Forgot password.

• Given: The user navigates to the login page.

• When: The user selects the <forgot password> option.

• And: Enter a valid email to receive a link for password recovery.

• Then: The system sends the link to the entered email.

• Given: The user receives the link via the email.

• When: The user navigates through the link received in the email.

• Then: The system enables the user to set a new password.

By looking at the example of a typical user story, you can conclude that the statements given will cover all the required user actions. It is also considered to be a universal solution for the majority of different user stories.

2. Rules-oriented (in the form of a checklist);

The rules-oriented approach is relevant when the previous format is hard to fit in the Given/When/Then structure. Such situations can be: when a user story describes systems-level functionality; no details of test scenarios are required for the target audience; Given/When/Then doesn't fit the precise design and some constraints can appear in a particular user experience.

Here, the rule-oriented user acceptance criteria format is a better choice. Its structure is presented as a set of rules describing the behavior of the system that is used to draw scenarios.

Example.

User story: As a user, I want to be able to use a search field to type 'airline', 'destination', and 'journey duration' so that I can find suitable air ticket options.

Scenario:

• Basic search interface acceptance criteria

• The search field is placed on the top bar

• Search starts once the user clicks "Search"

• The field contains a placeholder with a grey-colored text: "Where are you going?"

• The placeholder disappears once the user starts typing

• Search is performed if a user types a specific airline, destination and journey duration, or all 3 combined

• Search is in 12 languages

• The user can't type more than 100 symbols

• The search doesn't support special symbols (characters). If the user has typed a special symbol, show the warning message: "Search input cannot contain  special symbols."

3. Other formats.

While the above types are the most widely used, other user story formats might be appropriate too. In addition, your team can write their own acceptance criteria that best suit the goals of your solution.

When Should You Write Acceptance Criteria?

There are many situations in different software companies, where choosing the time to discuss and write user acceptance criteria is unreasonable. This definitely leads to a waste of resources and other problems in the final stages of the product release. To avoid time and resources being wasted, acceptance criteria for user stories should be written at the earliest possible stage.

It absolutely shouldn't be done during the development or testing phase. Since in the remaining time of the project, a lot of work may need to be redone. This often puts pressure on development teams, as it is difficult to make fixes to code already implemented. Ideally, a development team should work on a specified list of user stories along with previously agreed user acceptance criteria.

Examples of Acceptance Criteria

To get a better understanding of the basic mechanism when developing acceptance criteria for user stories, let's look at a few more examples. They are presented as examples of common situations with predefined functionality and its user story.

Example 1.

User story: As a user, I want the website to have a search field so that I can find the necessary items to purchase.

According to the scenario-oriented approach, we use the Given/When/Then template to write user acceptance criteria.

Scenario:

• Scenario: User searches for items to purchase.

• Given: The user is already registered to make purchases.

• When: The user opens the "Items" page.

• And: The system displays search fields in the upper middle of the screen.

• Then: The system shows the user a list of all items.

• When: The user fills in the search fields with the preferred options.

• And: The user clicks the "Apply" button.

• Then: The system displays items in the "Search Results" section that match chosen names.

• And: The system shows the number of search results in the "Search Results" section.

Example 2.

User story: As a user, I want to request a card balance at an ATM so that I know my current balance and then withdraw money.

Scenario:

• Scenario: The user is requesting a credit card balance to withdraw cash.

• Given: The user is already a card holder.

• And: The card is valid.

• When: A credit card holder requests a card balance.

• And: The user is authenticated.

• Then: The system displays the total balance in the center of the ATM screen.

• When: The user requests cash.

• And: The dispenser contains cash.

• Then: The system ensures the cash is withdrawn.

• And: The system ensures the card is returned.

Hopefully, we've been able to show you the basic logic when writing acceptance criteria for user stories. Its value is essential in setting the boundaries of a feature's scope and guides the entire product development process.

Conclusion

All in all, if you want to become more proficient in writing software acceptance criteria, your team must follow a single product vision for user stories and their acceptance criteria. To achieve this goal, you must constantly strive, learn and grow.

However, it doesn't mean that you should choose a specific project method or type of user story to meet all goals. Primarily, choose one that best works for you in practice. Just remember that the correct acceptance criteria prevents ambiguity and helps both the clients and the QA team understand how the overall project expectations and requirements are being met.

By putting common effort into specifying the necessary features and defining relevant acceptance criteria, you automatically invest in your product's success. Following this logic, your product will add more value to your team and overall business prosperity.

At the end of the day, only you can successfully achieve initial business goals and make a better, error-free quality product, but, we are here at your disposal to share our experiences.

FAQ

Acceptance criteria is a list of conditions or requirements that the end product should meet to be accepted by users, customers, and other systems.

It is definitely better to start writing acceptance criteria at the earliest possible stage of product development. This way, your team will save time and effort before the final testing phase.

Scenario-oriented and rule-oriented acceptance criteria types are considered to be the most commonly used among user story formats. They can be distinguished by the type of illustration. The first is presented in the form of scenarios that illustrate each acceptance criterion separately. The second is represented as a checklist.

User Story Acceptance Criteria Given When Then Examples

Source: https://lanars.com/blog/acceptance-criteria-for-user-stories

Share this post