Acceptance Criteria-Driven Development

Coding Against the Acceptance Criteria of a Story

12 March 2014


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.

Backlog grooming: 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.

Sprint planning: 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.

Sprint cycle: 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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Matt Chocqueel-Mangan, CSM, 3/13/2014 6:55:26 AM
Hi Prakash - thanks for posting this. We're focusing a lot on making sure acceptance criteria are baked in to every story so this is really helpful. In your experience, is it possible for POs (possibly with the help of QAs) to write acceptance criteria that can directly feed into automated testing (e.g. using tools like Cucumber). Do you (or any other readers) feel this can add more benefits than complications?
Prakash Mallappa Pujar, CSM, 3/13/2014 8:34:48 AM
Hi Matt, Thanks for your attention on this article. In our case, PO is not writing the acceptance criteria (AC) for Story. He only writes AC for an Epic. Stories are created by team and team itself adds the AC to all the Stories that will satisfy the AC of the Epic.
I have no idea on Cucumber and hence I am not able to answer your query on this.
Matt Chocqueel-Mangan, CSM, 3/13/2014 12:19:59 PM
Hi Prakash. OK, thanks for clarifying the distinction between who rights ACs for Epics and ACs for Stories - make sense.

You must Login or Signup to comment.