Last night I had a great opportunity to deliver this slide deck to the Turner…
Did We Build the Right Product? And, Did We Build the Product Right?
Acceptance criteria are important. Unfortunately, we often overlook or undervalue it as an aspect of the iterative planning process. It is 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 the 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 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 horseshoes here, and there is no partial acceptance: either the acceptance criteria is met or it is not.
When to define our Acceptance Criteria?
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 the 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 complete and working as expected. Express criteria 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 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. Criteria should state intent, but not a solution. (e.g., “User can approve or reject an invoice” rather than “User can click a checkbox to approve an invoice”). The criteria should be independent of the implementation, and discuss WHAT to expect, and not HOW to implement the functionality.
The Given/When/Then format is helpful way to specify criteria:
Given some precondition When I do some action Then I expect some result
When writing acceptance criteria in this format, it provides a consistent structure. Additionally, it helps testers determine when to begin and end testing for that specific work item.
Sometimes it’s difficult to construct 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.