Acceptance Criteria

This is NOT acceptable!!! screamed Mr. Johnson as he stared down at my first High School English essay. “You’ve hardly used any adverbs or adjectives, the passive voice is non-existent and it has been written in pencil, not pen!” Having hoped for an A grade, I stood there shivering with fear, going crimson red in embarrassment, unable to comprehend why all my efforts had gone to waste. It was quite simple really: Mr. Johnson had not provided my class and I with any acceptance criteria when he had set the essay as our homework task the week before.

In order to get what you want, it’s a major benefit to be explicit from the start.    

What are Acceptance Criteria?

The name “Acceptance Criteria” is fairly self-explanatory; the criteria that judges if something is acceptable based on the expectations of the client. Before any project in software development or elsewhere, there is a logical requirement for planning and estimation of resources and time. Acceptance criteria aid in the division of tasks, which can then be budgeted and assigned.

In Agile Methodology

In Agile, acceptance criteria, sometimes referred to as “Conditions of Satisfaction”, are seen as the predefined requirements that must be satisfied in order to be accepted by the user, customer or other stakeholders. They can be seen as the “definition of done” in that they indicate when a user story can be considered tested, accepted and complete. In other words, the fundamental aspect of acceptance criteria should be that they provide a clear description of what the user wishes to gain from the development of the product; the intent of the client or what he wants. Each user story certainly has more than one acceptance criterion, which in addition to being functional whilst maintaining a degree of flexibility, are independently testable.

The Writer(s)

In most cases, acceptance criteria originate from the Client and are generated by the Product Owner and are written before the development of a feature in order to provide guidelines. However, it is argued that to be more effective they should be the result of a joint effort with the development team. The former has traditionally been adhered to on the notion that the Product Owner is more aware of the customer’s needs than the members of the development team. Regardless of this, unless the client or product owner has a comprehensive knowledge of software development and acceptance writing criteria, at least one member of the development team should read and approve them to ensure that there are no technical misunderstandings and unsolvable problems on the horizon.

The Agile Practice Guide itself, on the other hand, recommends Acceptance Test-Driven Development (ATDD) through which “the entire team gets together and discusses the acceptance criteria for a work product”. Involving developers in the construction of acceptance criteria is a clear benefit since it allows their involvement in product strategy, whilst their likely superiority regarding hands-on knowledge of potential difficulties, plus their input on improving a project, will undoubtedly aid effectiveness.  

Clarity

As a set of statements referring to the expected outcome, acceptance criteria should be adequately detailed and defined but, at the same time, clearly expressed in simple language to avoid any ambiguity. If understood by all, and in particular the people who are actually working on the project, there is little or no chance of misinterpretation. As each criterion should be given a clear pass or fail result; there are no grey areas as to whether it has been met or not.

Whereas a user story itself may be based on a more general need (a scenario); “I require User Accounts to allow new customers access to our system and set up a buyer’s account”, acceptance criteria specify the details; the personal information a user must enter to create an account; a.Name, b.email address, c.cellphone number, d.chosen method of payment, etc. However, be aware of including too much detail and also that acceptance criteria are employed to state intent, not solutions. It is the software development team’s responsibility to ask for clarification where needed and then to search for the solutions.

Testability

In the same way that acceptance criteria have to be clearly written for all to understand, they must be easy to test so as not to leave anything in doubt. Thus, when deciding upon criteria, one should consider if they can be properly tested. Again, ambiguity can cause serious problems if, for example, a criterion was written as; “Allow payment by all major credit cards”. The writer of the criterion, the development team and the testers will almost certainly all have different ideas in mind about what constitutes a “major credit card”. Reworded as; “Only allow payment by Visa, Mastercard, American Express and Discover” is specific, understandable and testable.

Common Understanding

To a certain degree, common understanding may appear as repetition of points made in both clarity and testability but it is the element which needs emphasis as everyone must be following the same script. Any confusion concerning what the acceptance criteria are really about will undoubtedly damage the flow of a process and its productivity. Additionally, as an important component of every user story, the process of creating and agreeing on acceptance criteria is another chance for communication amongst the whole team who are working on a project.

How to Utilize Acceptance Criteria

As in much of Agile Methodology, formatting user story acceptance criteria is flexible depending upon the organization and its abilities. Nevertheless, there are two main approaches utilized; Given/When/Then and Verification List. How to use them is relatively straightforward:

Given/When/Then Acceptance Criteria

In a similar way to the scenario-orientated technique used in formatting user stories, the three parts of the Given/When/Then approach follows the template which depicts: Given (the initial condition), When (action taken), Then (the result of taking action). As an example of this, imagine your client expresses the security requirement that customers’ messages to his company are sent through valid email addresses. In other words, the client wants a similar result to the one that diverts emails to JUNK rather than INBOX:

Given-The customer’s email address is valid.

When-The customer’s email address is authenticated.

Then-The customer’s email message is sent to the company’s email address.

And, if sent through invalid email addresses:

Given-The email address is invalid (it is not a genuine customer).

When-The email is authenticated.

Then-The online profile is flagged as incomplete.

Verification List Acceptance Criteria

Described as a rule-orientated format, Verification List Acceptance Criteria is an even more basic technique. It originates from the idea that the whole team pre-defines a list of straight pass/fail statements. Going back to our credit card example;

Pass- The customer can pay with Visa, Mastercard, American Express or Discover.

Fail- One or more of the credit cards required for payment is not usable.

If you and your team prefer to approach things in a very black and white way, then the simplicity of this technique may be preferable. However, simple does not always mean easy and often ends in confusion. So, there should still remain the requirement to also use this method within the framework of agile methodology.

Utilization

Ultimately though, whichever technique is used, and note that there are variations of practices in existence, effectiveness comes from utilizing the one that your team understands best and is able to work with. Initially, using a standard template is recommended since it provides a solid base to writing and following through on the acceptance criteria. As your team advances through different projects and gains more experience, both positive and negative, acceptance criteria can be modified to suit your conditions and abilities.

Use acceptance criteria as a reference point for everyone involved in the user story and sub-divided tasks so that they keep on a steady and well-guided course and do not deviate from the pre-stated goals and requirements. Similarly, if adhered to, they avoid the chance for team members, who are running behind on a project, from cutting corners and declaring something done. If it has not met the requirements and passed, it cannot be considered done.

In the end, if you want to produce an A+ end product, without incurring the wrath of your equivalent of Mr. Johnson, my old High School English teacher; make sure he or she clearly defines what is required, you and your team do what is needed and solid, understandable acceptance criteria are put in place before every action.