Join the DZone community and get the full member experience.Join For Free
Originally written by Steve Povilaitis at the LeadingAgile blog.
Did We Build the Right Product? And, Did We Build the Product Right?
Acceptance criteria are an important yet, in my experience, often overlooked or undervalued aspect of the iterative planning process. Acceptance criteria are super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceived acceptance criteria. When we clearly define acceptance criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction. In other words we’re able to answer these two important questions: Did we build the right product? And, Did we build the product right?
What are Acceptance Criteria?
Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or other in the case of system level functionality, the consuming system.
Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level. Acceptance criteria constitute our “Definition of Done”, and by done I mean well done.
We’re not talking about horsheoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.
When are Acceptance Criteria defined?
A trap that I encourage my teams to avoid is writing acceptance criteria after development has started. This leads to merely verifying that the functionality built works rather than verifying that the functionality meets user needs and expectations. If we write and review acceptance criteria before implementation begins, we’re more likely to capture the customer intent rather than the development reality.
What makes good Acceptance Criteria?
Acceptance criteria define when a work item is completed and working as expected. Acceptance Criteria should be expressed clearly, in simple language the customer would use, without ambiguity regarding the expected outcome. This sets our testers up for success, since they will be taking our acceptance criteria and translating them into automated test cases to run as part of our continuous integration build.
What. Not how.
Another trap that I coach my teams to avoid is ‘The how trap.’ Acceptance Criteria should state intent, but not a solution (e.g., “A user can approve or reject an invoice” rather than “A user can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT is expected, and not HOW the functionality will be implemented.
Acceptance Criteria Formats
The Given/When/Then format is helpful way to specify acceptance criteria:
Given some precondition When I do some action Then I expect some result
When we write acceptance criteria in this format, it not only provides a consistent structure, but we are also helping testers determine when to begin and end testing for that specific work item.
Sometimes it’s difficult to construct acceptance criteria using the given, when, then, format. Particularly when dealing with system level user stories. In those cases, I’ve found that using a verification checklist works well.
Another advantage to Verification checklists is that they are also simple to individually mark as complete as we implement functionality.
What are some of the challenges or techniques you’ve found when writing acceptance criteria?
Published at DZone with permission of Mike Cottmeyer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.