Card (User Stories) – Stories are traditionally written on notecards, and these cards can be annotated with extra details. Develope user stories through coversations with the product owner.
Conversation (Developing Acceptance Criteria) – details behind the story come out through conversations with the Product Owner.
Confirmation (Testing the AC) – acceptance tests confirm the story is finished and working as intended.
User stories - description of an objective a person should be able to achieve when using your website
Format:
As a who, I want what, so that why
For example:
“As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.”
Meeting with product owner Acceptance Criteria develop from QA from discussing user stories “As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.”
How many different privacy levels do they need? Should changes apply to collections/individual photos? Should they be sent a confirmation email? What should the default setting be?
Acceptance criteria define the bounds of a user story and are used to confirm when a story is complete and working.
You demonstrate functionality by showing how each criterion raised in conversation is satisfied from the tests.
Removes ambiguity and encourages thinking from user perspective
As mentioned above, the Product Owner decides on the priority for all remaining work. This forms the “product backlog”. Items that are at the top of this queue will have a lot more detail than items towards the bottom.
There is little value adding a lot of detail to stories that are at the bottom of the backlog because a lot might change before you get around to working on them.
Acceptence Criteria is only needed for current user stories, and shouldn't be done for everything.
Acceptence Criteris is what you test.