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.