Acceptance Criteria 101

Acceptance Criteria 101

Acceptance criteria are also sometimes called the “definition of done” because they determine the scope and requirements that must be executed by developers to consider the user story finished.

I’m gonna jump in Explaining Acceptance Criteria (In Context of User Story Writing) with an example technology used in a movie that scared me out of my mind as a child. In fact even as an adult i get the occasional horrid flashback from the Grotesquely disfigured half-fly-half-man in the incarnation of Jeff Goldblum from 1986s The Fly.

So for you who haven’t seen the movie. The Premise behind the techology used is quite simple. A man designs a teleportation device (2 Pods). You place a object (Or living entity in Pod A) press a couple of buttons and then the object teleport to Pod B.

The Initial User Story the technology:

As a Courier Service,
i would like to teleport Objects from one location to another,
so that Objects can quickly be transported to desired destinations.

Acceptance Criteria can Read something like this

Scenario: Teleport a Single Object

Given that a single non living object is placed in Pod A,

When the doors are sealed and the teleportation sequence is initiated,

Then the Object disappears from Pod A and reappears in Pod B in it’s original condition.

Lets Quickly Look at the characteristics of the above Criteria.

• Is Testable (Clear Pass / Fail Result) – Yes if the object doesn’t manifest in Pod B then it Failed. So tester can Test it.
• Describes the Result of an Action (Defines What needs to be achieved not the How it is achieved) – Yes in this case we know that the object must teleport to Pod B from A. We cant really tell how it achieved by the Criteria. The Definition of Done has been clarified. Focuses on the End Result of the Story.
• Clear & Concise – Yes we know that it must a non Living Object (Only one) and it must be placed in Pod A and the sequence must be initiated. (But we might need some more scenarios – What if a Living Entity is in Pod A?
• Provides User Perspective – Yes the user (Courier Company) wants the object to reach it’s destination.

But what Happened ? Some Scope Creep Set in. Our dear ol Jeff decided it wasn’t merely good enough to successfully teleport Objects. What would happen if you stuck a living creature in there? (a wonderful advantage of acceptance criteria – it prevent scope creep). So he had to create a whole new User Story (The original Story passed and it’s clear that The initial story is completed (Definition of Done)).

The New User Story :

As a Traveller, i would like to Teleport myself from one location to another, so that i can reach my destination in the shortest possible time.

Given that a Single Living Entity enters Pod A,

When the Pod Door Is sealed and the teleportation sequence is initiated,

Then the Living Entity disappears from Pod A and Appears unchanged in Pod B.

hmmmm thats a whole new User Story with whole new Acceptance Criteria. What has this show us about Acceptance Criteria in context of a user story ?

• Helps manage expectations – we know exactly what to expect from each user story Jeff needs to teleport
• Define the Scope & Reduce Ambiguity – we know that one living entity needs to enter the pod (So the scope is for one entity – but what if a fly is also in there with you so 2 living entities? we’ll thats out of scope)
• Establish Testing Criteria for Q&A – Testers find Acceptance Criteria especially useful as it guides them to test if a story is done. In this case we must test the device with 1 entity at a time, and we know what result is expected in Pod B. The Entity needs to Appear unchanged in Pod B (So no bloody half fly half man )
• And serves as Defense against scope creep – When Jeff started deciding he’s gonna start teleport himself instead of objects the acceptance criteria was very specific that the story applies to either living or inanimate objects.

Given / When / Then Format

The Traditional User Story formatting can be stated as “As a (intended user – Who ? ), I want to (intended action – What ? ), so that (goal/outcome of action – Why ?)”. So similar to user stories Acceptance Criteria can also be expressed with a similar format.

The Given / When / Then Acceptance criteria format. User acceptance criteria in given/when/then format follows the template: “Scenario: (explain scenario). Given (how things begin), when (action taken), then (outcome of taking action).” This Format is a personal preference of mine as you can see from the 2 examples in this article , but it is not needed in that format – if your team understands it and is able to work off it then you’ve managed to create effective acceptance criteria. No Matter what the format look like.

Common Mistakes

• To Narrow – Make sure that your Criteria is not to Narrow (Unless it’s needed – in our example our narrow Criteria was needed to prevent half fly men to be created)
• To Wide – Make sure that the Criteria is not to Wide- this increases the risk of the associated story to be to bulky & may introduce fat into the features. We Know in our example it wasn’t to wide as the testing for a living entity was very different than the testing for a object.

Other Additional Tips

• All User Stories should have at least one Acceptance Criteria (Even Stories in the backlog)
• Acceptance Criteria must be written before implementation of a Story. You’ll miss out on all the benefits of Acceptance criteria if you write it after implementation.
• Team Members write the Acceptance Criteria & the Product owner verifies it – this ensures that the product owner and team have a shared understanding of each story.

Closing Remarks

Now i hope this article gave you a bit of insight into the world of Acceptance Criteria. So go out there and add it to your user stories.