How Do I Use Acceptance Criteria To Detail A Story

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

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

How Do I Use Acceptance Criteria To Detail A Story

by rpannone on Mar 20, 2010

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

How Do I Use Acceptance Criteria To Detail A Story — Document Transcript