I think the terms acceptance criteria, acceptance tests etc have caused a lot of confusion, in some environments they are separate, in others they are blurred. I always strive to ensure that the acceptance criteria for a theme, epic or story is defined. This acceptance criteria is the outcome and agreement with stakeholders, customers and SME’s.

Guidelines for effective acceptance criteria:

• It is a high level generalisation that allows for rapid agreement with customers, stakeholders. SME’s etc
• It is very effective in gaining a collective understanding of the intent by all
• It provides the direction of what they want and helps guide teams
• It’s generalisation should not make it change, a change to acceptance criteria would be a total deviation in direction and intent and will need to be addressed
• It provides us with a boundary on when to stop i.e. this is what we want, nothing more, nothing less
• It is implementation agnostic i.e. my implementation can change and in most cases should never affect it
• It’s generalisation should deliberately trigger questions, conversation and challenges by all, it is a collaboration promoter
• It should only ever exhibit a YES / NO answer when asked ‘Is this what you want?’

Why is generalisation so important?

Generalisation keeps us at the high level. I have run many workshops where people dive so deep into detail before they have even agreed on the intent on what they want. Maybe it is human nature for a lot of people but it totally derails the intended outcome of a session to gain agreement on intent. To obtain generalisation I use ‘roll-ups’, as soon as I see detail and conversation about detail as ask how can we ‘roll this up?’ so we can move on and ensure flow.

For simplicity sake lets walk through an example at say the theme (Feature Set) or epic (feature) level:

The stakeholder says ‘we want to put new customers on the system as we need orders to belong to a registered customer.’

Thirty seconds later someone immediately starts making statements such as ‘We need their company name, also their email, the telephone numbers, I think we will need 30 characters for the name ….’

We stop this and ask ‘Do you agree that to register the customer we will need the customer’s information YES/NO?’, we get ‘YES.’

Customer information is the generalisation for all the details such a name, telephone , email etc. Think of apples as the generalisation for granny smith, golden delicious, gala etc.

This leads to:

Given our company has a new customer
When the user provides the customer information
Then the customer should be registered on the system

The group agrees that this is what they want. The stakeholder then says that ‘one of our organisational objectives is that our information must be of the highest quality, as it has caused us major headaches in reporting and wasted costs in data cleansing exercises.’

‘So you want this customer information to be of the highest quality?’  ‘YES.’

Straight away another person starts ‘You have to make sure that they provide a company name, oh and telephone numbers need an area code, better validate their email to …’ , time for a roll-up !

‘Do you want to check the customer information before registering?’  ‘YES’

Given our company has a new customer
When the user provides the customer information
and the customer information has met the right quality
Then the customer should be registered on the system

Our stakeholder says that ‘we always need to keep the customer up to date on their interactions with our company. So I want you to inform them, maybe through email that they have been registered’, straight away Mr Detail says ‘We can send them an SMS instead, but wait what information are we going to send them? I think we should show all registered account information, oh and we need our logo if going via email, we will need an SMS gateway, and an email one to if we are going to use email, what happens if their email is invalid and it bounces’,  time for a roll up again !

‘Do you want to notify the customer that they have been registered’,  ‘YES, they answer.’

Now we have:

Given our company has a new customer
When the user provides the customer information
and the customer information has met the right quality
Then the customer should be registered on the system

Given that a new customer has been registered on the system
When our company sends the notification to the customer
Then the customer should receive it

The above example shows how quickly we can get agreement and direction with simple facilitation. You will become a stakeholders friend by doing this as most of them , including senior management dont know about the detail nor do they have time for it, they are there to provide guidance and direction.

Our acceptance criteria is going to trigger massive amounts of questions, this is what we want, this is its intended purpose.

WE WANT THIS:

Given our company has a new customer
When the user provides the customer information
and the customer information has met the right quality
Then the customer should be registered on the system

Given that a new customer has been registered on the system
When our company sends the notification to the customer
Then the customer should recieve it

WE NEED ANSWERS TO THESE:

• What do we define as a new customer?
• What user? Who are they? Which department? Is it any user?
• What customer information?
• What is meant by the right Quality?
• What notification? What content does it have? Is it email, SMS? Do we need branding?

All these questions allow us to iteratively and incrementally expand our business needs. The example I have shown is at the higher level of the cone of uncertainty. Many people will ask where do the details go. This is totally up to you and depends on the flexibility within the environment you are working in. Sometimes organisations will insist that these details are bound to the epic, others will be quite happy for these details to be in the acceptance test, there is no wrong or right answer.

I notice you have used Given-When-Then, is this the only way?

I have used (GWT on a number of projects for acceptance critera (AC.) I will be honest and say that at the very beginning it did not grab me that much but over time and through a few adjustments and learnings on how I was doing it, I came to realise that it is a very effective notation. There are many formats,  I think agile use cases are just as good and have used both, they achieve the same outcome.

You’re at the theme / epic level what about story acceptance criteria?

So lets say we were at the lower end of the cone of uncertainty,  say for our above epic, we decided to implement this epic by cutting the following stories:

Story: Register new customer

Narrative:
As a valid user
I want to be able to register the customer
So that orders can be allocated to their account

Story: Validate customer information

Narrative:
As the system
I want to validate the customer information before registration
So that our data quality is ensured

Story: Notify registered customer via email

Narrative:
As the system
I want to notify the customer via email when they have been registered
So that they are aware their account is ready

Story: Notify registered customer via SMS

Narrative:
As the system
I want to notify the customer via SMS when they have been registered
So that they are aware their account is ready

Lets take the first story Register new customer. At the story level the acceptance criteria (conditions of satisfaction) are still going to be generalised and the principles are still the same.

Story: Register new customer

Narrative:
As a valid user
I want to be able to register the customer
So that orders can be allocated to their account

*Acceptance Criteria

Given our company has a new customer
When the user captures all the customer information
Then the customer should be registered on the system
but the information should not be validated

*I normally use conditions of satisfaction for stories for differentiation purposes

This is very effective even down to this level it is providing direction to the team and has established a boundary on when to stop i.e.this is what we want, nothing more, nothing less for this user story.

It’s generalisation should not make it change

To emphasise this point if the product owner decided to pull the story for SMS notifications it would not change the intent of the original acceptance criteria for the epic. If you stick to this there will not be much refactoring back to the parent.