Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 1 of 2

How do I use acceptance criteria to detail a story

Acceptance criteria, represents the details for a story and specifies the desired behavior and functionality

the system-software must implement.

Acceptance criterion is high level tests to verify and validate the completeness of a story or stories

implemented during a Sprint/Iteration, expressed in a business domain language. These tests are created

ideally through collaboration between business customers, business analysts, testers and developers;

however the Product Owner (aka, the business or customer) is the primary owner of these tests.

As the stories pass these tests, the Product Owner can be sure of the fact that the developers are

progressing in the right direction about how the application was envisaged to work and so it's essential

that these tests include both business logic tests as well as UI validation elements (if need be).

Acceptance criteria is used to describe the team’s definition of “done” for a story. Acceptance criteria is

also used at the end of a Sprint/Iteration, when demonstrating to the Product Owner what the team has

implemented.

A story is not considered complete or “done” until the acceptance criteria/tests have passed.

One of the key characteristics that make stories so fitting for delivering value early and often is that they

focus on describing the source of value to the Customer, instead of the mechanics of how that value is

delivered. Stories strive to convey the Customer wants and needs, the what and why and not the specifics

of the solution or the details about what it will take the team to deliver the story.

Let’s look at an example to better illustrate this difference between what and why and how. Figure 1.0

shows an example of acceptance criteria that goes into too much detail about the solution rather than

focusing on the goal - the Customer’s need and requirement. All three tests depicted address the user

interface - effectively suggesting an implementation, which isn’t what we want. While doing that, they’re

also hiding the real information - what are we actually testing here - behind the technology.

Figure 1.0 - Acceptance criteria focusing too much on the implementation

Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 2 of 2

Sidebar

Depiction of the user interface is just as much a part of the details behind a story as acceptance

criteria. Wireframes and screen mockups are often attached to stories as a basic visual guide used

in interface design.

We should try to formulate acceptance criteria in terms of the goal of the story and leave the solution up

to the developers and the Customer to decide and discuss at a later time, during Sprint Planning and a

Sprint, when we’re validating and verifying the acceptance criteria and implementing the story itself.

Figure 2.0 illustrates a possible rewrite of the tests in Figure 1.0 in a way that preserves the valuable

information and omits the unnecessary details, which only clutter our intent.

Figure 2.0 - Trimmed-down version of the acceptance criteria from Figure 1.0

Notice how a developer is just as capable of figuring out what to test as they would be by reading the

more solution-oriented acceptance criteria from Figure 1.0.

The volume and focus of the words we choose to write our acceptance criteria will have a big impact on

the effectiveness of our tests as a tool to verify and validate the value delivered when the story is being

implemented.