The easy way to write acceptance criteria

We all know that a user story should not aim to capture all the detail about a requirement or business need. It is more of a promise that a conversation will take place, the options explored and some work will be done that will deliver that business value.
One of the key things to make sure of, when writing user stories, is to have a clear view as to when a piece of work is completed. The normal way of doing this is to document a set of acceptance criteria against a user story. What we don't want though is to write a 20 page requirements document as acceptance criteria.
We are NOT aiming to capture an exhaustive set of tests here, What we capture is a list of things that we must not forget to test.

Acceptance Criteria need to be:

• Clear and precise (not vague)
  
• Address the core business need/value we are producing
  
• Give concrete examples
  
• Fit on the back of a 6x4 index card

They are not:

• A full and complete list of tests to be performed (these get discovered during those daily conversations with the product owner)
  
• Address vague needs (All blah should ....)
  
• Trying to capture all edge cases (Give the QA guys some credit!!)

The easiest way of doing this if to use a Given - When - Then format.
Given - A condition or context
When - This event or action occurs
Then - I expect this observable/testable result

This forces us to express things in clear unambiguous language detailing the behaviour/interaction we expect