So how does an Acceptance Criteria look like? Let’s say we have a simple user story called “Login”:

As a registered user i want to log in so that i can view my personalized report

Acceptance Criteria are then described as scenarios. As an expample let’s look at a typical main success scenario for the user story above:

Given a registered user u
When entering username FooFoo and password BarBar
And logging in
Then the personalized report for user u is shown.

A story can have as many Acceptance Criteria as necessary to consider it as done. Don’t be fooled to believe you can define every Acceptance Criteria upfront. As the team gains more and more knowledge while proceeding in an iteration more Acceptance Criteria may be discovered. Your initial set of Acceptance Criteria should be enough to make everyone comfortable to deliver that story.

So why this format of “Given” “When” “Then”? On my current project we use RSpec, a Behavior Driven Development framework for Ruby. You start by writing your stories with the scenarios in plain text files:

Story: Login
  As a registered user
  I want to log in
  So that i can view my personalized report
 
  Scenario: login successful
    Given a registered user u
    When entering username FooFoo and password BarBar
    And logging in
    Then the personalized report for user u is shown.

Each Given, When, Then is a step and i can define these steps in Ruby:

steps_for(:login) do
  Given("a registered user $user") do | user |
    user.should exsist
  end
  When("entering username $username and password $password") do | username, password |
    page.type(username, account)
  end
  When("logging in") do
    page.login
  end
  Then("the personalized report for user $user is shown") do | user |
    page.should be_personalized_for(user) 
  end
end

The great thing about this is that you can reuse the steps for other scenarios and hook up the RSpec framework with functional testing tools like Selenium or Frankenstein to have real end-to-end testing. In addition you can integrate the tests into the Continuous Integration server to have automated regression testing. The effort the team puts into fledging out Acceptance Criteria is directly translated into automated test code producing minimal waste.