We turn the wishes of the customer into Acceptance Criteria: 3 practices

Acceptance and Completeness Criteria: How Not to Confuse

Since the acceptance criteria and the definition of "completeness" apply to user stories, let's agree on what to mean by each term: what do computer engineers do

Definition of Done is a criterion of completeness, a global checklist of requirements for all user stories. Completeness criteria describe the process as it should be designed. The team creates a Definition of Done for itself: this is a list of agreements with Product Owners, a business party, or between team members.

Acceptance Criteria - Acceptance Criteria, details required to complete a specific user story, a description of what needs to be done. Acceptance Criteria are composed of one or two people, separately for each User Story.

User Story is a topic for conversation about how to satisfy user needs.

Acceptance Criteria are prescribed separately for each User Story, and Definition of Done are general requirements for all User Stories of the project.

Definition of Done

Completion Criterion  is a list of requirements that any user story must meet for the team to call it complete. The completion attribute list applies to absolutely all stories or to all items in the backlog.

The Definition of Done is an agreement on how the team will work in the process. One of the elements of the scrum set up is the team working agreements on completion criteria and the creation of estimation baselines.

For example, the usual criterion of completeness for development teams is that each specific task has a code review step. There may be such a criterion that the change has no known defects - everything that was found has already been closed and repaired. The business party is also included in such agreements: the customer or the Product Owner. Definition of Done are clear criteria by which we agree to work and create a quality product every iteration.

Let's see how the completion criteria for three work items will look like:

Make a Scrum presentation.

Make a DevOps presentation.

Make a PMP presentation.

Completion criteria common to all three tasks may be as follows:

presentation pages are numbered;

texts were proofread by the editor for errors;

contains copyright information;

each page has a company logo;

at least 30% of all presentations have visuals;

the presentation passed the "4 eyes principle", that is, it was watched and approved by two people.

Acceptance Criteria

If a user story is created as some kind of statement of intent so that the team is free to find a solution, then the acceptance criteria are the exact details unique to each User Story, a set of conditions confirming that it has been implemented.

Acceptance criteria can always be verified with a clear yes / no parameter. It is impossible to fulfill some criterion in half: it is either fulfilled or not. With Acceptance Criteria, the development team knows what the final result of a specific requirement should look like.

Alongside the acceptance criteria are similar, but not identical, terms from Henrik Kniberg “How to demo” or Mike Cohn's “Conditions of Satisfaction”.

In general, Acceptance Criteria must meet the following characteristics:

Binary: can only have two unique outcomes - success or failure. There can be no term “partial success” because the acceptance criterion should always give “green” or “red”.

Unambiguous: they can only be interpreted in one way. It is wrong to prescribe: "The form is painted in a bright color" or "The system must be user friendly", because such criteria can be interpreted in different ways.

Verifiable: Must be written so that the client can quickly verify them.

Complete: The list of criteria should include all functional requirements. Everything that needs to be done for each requirement is described in the acceptance criteria.