1. 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 1 of 2

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.
Written by: Russell Pannone, Copyright © 2010 US-Airways. All rights reserved. Page 2 of 2