Journey of organizing a SCRUM-TEAM of an amateur scrum-master (P4): Acceptance criteria

Tram Ho

In order for a scrum-team to work well, to meet customer requirements in the production of software, in addition to ensuring the operation that best suits the process (suitable only, can not impose 100% must be identical). ), Scrum-master can support the team by providing definitions, concepts, examples for the team to follow.

An experienced scrum-master will have a higher “price” on the “transfer market” because they have a “treasure” of how to operate, how to write articles, and connect between members. in teams, setting standards for working together between teams within the same company.

In this article, I will discuss a concept: “Acceptance criteria” and how to put AC into work.


Definition of “machine”

Acceptance Criteria is a set of test scripts built to ensure the software works as expected of users and customers.

Note: This set of test scenarios may not need details like test cases (but must be a subset of test cases).

For example:

User story : As a user, I want to have an online registration function, so I can start shopping online.

We can form the AC as follows:

Simple definition

Acceptance Criteria is a list or checklist or descriptive bullet points, representing the requests (in the form of desired results) of customers for each user-story / task.

The acceptance criteria (Acceptance Criteria) usually only have two states PASS / FAIL PASS: Confirmation of completion FAIL: Not completed

(This is why there is a checkbox in the image above).

In the software development process, only when all Acceptance criteria in the user-story / task are confirmed completed can the user-story / task be transferred to other job states.

Why is the Acceptance criteria important?

Acceptance criteria: Represents the customer requirements for products in each stage

In each stage, to deliver products to customers, the product must meet all representative requirements.

The product will fail or the customer will not accept it if the development team does not meet the representative requirements.

-> When defining acceptance criteria from the beginning, the team will ensure higher product quality and higher customer satisfaction.

The purpose of accepting acceptance criteria

Boundary determination : The Acceptance criteria help the development team to define the boundaries of the story / task.

In other words, AC will help the team get a “confirm” of how the application / function works as expected. This means the story / task is completed.

Reach consensus : Acceptance criteria will provide a common voice between the development team and the customer.

Customers know what their expectations will be met, and the development team knows exactly what conditions need to be met.

As a basis for test-case construction : Acceptance criteria are the minimum test criteria (minimum conditions) to ensure the system works as expected.

From these criteria, the tester will expand the cases to build up detailed test cases or test-plans, automation-tests.

These are the criteria for planning and cost estimation : Acceptance scenarios support the precise separation of story / task into tasks / subtasks. From there it is possible to make a plan, accurate cost estimates. (The cost here is the time it takes to complete, the number of personnel needed, …)

How to use accept criteria

Acceptance criteria are included in the description of the story / task

The developer, when developing modules / products, will “test” the functions according to the acceptance criteria. (Minimum requirement to transfer status of stories / tasks)

The test relies on acceptance criteria to build test cases. (Acceptance criteria are a subset of test-cases)

When to create Acceptance criteria

Acceptance criteria need to be created / reviewed / confirm before the programmer / programmer begins to execute his / her job.

-> In order for the software development phase to begin, the team and the product owner should agree on the minimum level of acceptance criteria.


Once the acceptance criteria have been clearly defined:

  • Dev / tester will not have to exchange back and forth with BA / PO about customer expectations of the product.
  • The tester will write down the correct test case.
  • Dev / tester will not have to switch back to Developing / Testing state.
  • The team understands how the system features work.

Who created the Acceptance criteria

Acceptance criteria are usually created by PO / Customers when making requests to the development team.

After receiving the requirements, the BA will perform “translation” into “technical” language or general format and issue Acceptance criteria in accordance with the general standards of the development team.

Devs may also be the ones who give acceptance criteria if they find that the ACs in the article are not enough or have unreasonable requirements. But it should be noted that the generated AC must be a subset of the test-case

If the Acceptance criteria are not derived from the PO but were developed by the development team during the “Refinement meeting” (clarifying the requirements at the beginning of the article), it should be reviewed by the PO / “responsible person” to eliminate the requirements. redundant, unnecessary.

The format of the Acceptance criteria

Each software company will have different top formats so the format of AC is also multifaceted , I personally encounter the following 2 types:

Rules-oriented : Checklist – a form of list

Scenario-oriented : Given / When / Then (GWT) type

Rules-oriented: Checklist – a form of list

Outcome / Result : List of acceptance criteria

For example:

User story: As a credit card holder, I want to view my statement (or account) balance, so that I can pay the balance due.

Acceptance criteria:

  • Display statement balance upon authentication. Say for example $ 1560
  • Display total balance. For example $ 3560. Here the balance due from the current period is $ 2560 and past balance due is $ 2000.
  • Show Minimum payment due. For example $ 140
  • Show Payment due date. For example May 16th of the current month
  • Show error message if service not responding or timeout. For example ‘Sorry, something went wrong with the service. Please try again. ‘

Scenario-oriented: Given / When / Then (GWT) type

The GWT type is commonly used in behavior-driven development (BDD) – behavior-driven software development & is built to be ready for writing automantion-tests. There is a separate guide for making GWT types:

For example:

User story: As a user, I want to have the password retrieval function for my account, so that I can access the account when I forget the password.

The GWT type is often written in place of the task / sub-task problems in the story / task.

However, this approach has disadvantages:

  • It takes a long time to build a detailed article.
  • Difficult for new access or non PO / BA roles

Therefore, usually GWT type is applied in companies … large scale. In Vietnam, very few companies use GWT, but you can refer to this method here

When starting a build team, it is extremely important to choose a common working standard. As a scrum master, try to advise your team well on what to do.

Thank you for reading my article.

Share the news now

Source : Viblo