The acceptance criteria (AC) of a user story consist of set of test scenarios that are to be met, to be assessed as complete. Acceptance criteria for a story are highly important and required in Agile, because the criteria indicate what exactly the product owner (PO) expects and what the Scrum team needs to accomplish. Test scenarios are captured as part of acceptance criteria, signifying the behavior of a feature after it is implemented.
We are familiar with test-driven development (TDD), in which a developer first writes automated test cases and does the coding of features to get them passed. On execution, these automated test cases will fail first and, over time as the developer completes the coding, these test cases get marked as passed.
Acceptance criteria-driven development (ACDD) is an Agile approach practiced by integrating TDD with acceptance criteria. Feature development takes place against the AC of a story. The developer understands the AC of a story and codes the feature to satisfy the scenarios of the AC. My Scrum team has been practicing this approach for some time now, and the results are awesome! The method reduces defect rates (as all the test scenarios would have been covered as part of AC), which increases quality and brings more value to the product by making the Agile process more Lean.
How do we begin with the ACDD approach? Well, there is no separate Agile event or artifact required to adopt this process. The events we have been following for Agile practices are enough. Following are the activities to be performed in Agile events to get started. I will not explain the details regarding these events, but what is needed for ACDD will be elucidated.
The PO clearly defines and updates the AC of epics and indicates his expectations. During the backlog grooming sessions, the Scrum team creates the stories for these epics to develop features. The AC of all these stories are discussed, updated, and agreed upon by the Scrum team. The PO guides the Scrum team on requirements of epics if required.
During the sprint planning meeting, team members review the AC of all the prioritized stories and update them if required. The ScrumMaster helps the team clarify any queries regarding the AC so that the team clearly understands and agrees to the objective of each story.
The developer picks up a story and starts coding the feature to meet the AC. The story is considered complete only if all the test scenarios of the AC are met.
The activities to be followed in order to build the feature within a sprint cycle by adopting ACDD are listed as follows and as shown in Figure 1.
The developer assigns the story to self.
He understands the AC.
He implements/codes to meet the AC.
The developer verifies against AC. On failure, he analyzes the reason, fixes the cause, and repeats the process. If the developer is unable to implement any step of the AC within the estimated time, the team can take a decision to create a defect or mark the story as incomplete.
On success, he moves the story to "done" and starts working on the next story.
Figure 1: Sprint cycle after adopting ACDD
To classify and include subjective test scenarios for acceptance criteria, the story can have multiple sections, such as "Positive Scenario," "Negative Scenario," and "NFR/Performance Scenario" under acceptance criteria. A sample snapshot image that signifies the different sections of acceptance criteria in a tool called JIRA looks as shown in Figure 2:
Figure 2: Sections of acceptance criteria
The main purpose of this article is to explicate acceptance criteria-driven development (ACDD). By mandating and capturing the acceptance criteria for every story, it ensures that the developer will build the features as expected by the PO and as required by the customers.