Creating and maintaining Acceptance Criteria seems to be a challenge in many Agile Teams.

A good set of Acceptance Criteria should in a couple of bullet points describe what this new feature should do, and preferably what it should not do. Mike Cohn calls them ‘Conditions of Satisfaction’ in his book ‘Succeeding with Agile’. These Conditions of Satisfaction can be the product owner’s expectations about what will be included and about what will not be.

Acceptance Criteria can be written in ‘given when then’ formula (efficient whet directly used for Test Automation), but it can also be written in a lightweight text. The Product Owner is usually the one who initiates the Acceptance Criteria. But the final AC’s should not only be the responsibility of the Product Owner. The whole team should contribute to the clarity of the User Story. A ’Three Amigo’ meeting, backlog grooming, refinement or any other discussion about a certain User Story is a perfect moment to go over the Acceptance Criteria. When discussing the User Story it seems clear what needs to be done and actually writing the conclusions down in the ticket seems like a waste of time. But it is not! Because the time passes, people forget, there are other priorities, conditions change, not everyone was present during the discussion…

Creating Acceptance Criteria is a creative activity. But not all members of Agile Teams are evenly creative in this department. Apparently not every person has the same ability to come up with a set of rules that would represent the feature’s functionality. IT professionals are often very creative in inventing new user friendly features, designing beautiful peaces of UI, writing efficient code… but when you ask them to write down a couple of lines in the User Story which would make it clear what the essence is of that added value – the creativity often stops right there. They might as well be writing a next new hit for Coldplay!

QA Officers can be of big help here: Acceptance Criteria are the base for executing Exploratory Tests, writing Test Cases, adding code to Test Automation scripts… so this is their playground. Next to taking care of overall Product and Process Quality, QA Officers should proactively engage in coaching the team members on how to write and maintain the Acceptance Criteria.

So, QA Officers of the world:

• Lead by example! Find opportunities (stand-ups, planning meetings, refinement meetings…) to show how it is done
• Do not criticise! Negative energy is not productive
• Stimulate by praising colleagues who make effort in writing good Acceptance Criteria
• Look for other team members who understand you and get their support
• Coach! Teach!