(I haven't listened to the podcast yet. I'm responding to the headline and other comments.)
I revisited c2.com lately to put the phrase "Acceptance Criteria" into perspective with all I've learned and read about XP, Scrum, etc. Here's what I've concluded:
- Early posts about User Story at c2.com include phrases like "conditions of satisfaction" and "acceptance tests".
- "acceptance tests" refer to automated tests, often but not exclusively written before production code (TDD at the level of the user-interface which has become more commonly known as ATDD, BDD, Spec by Example)
- "Acceptance Criteria" (capitalized and all) shows up later and introduced not by the same authors as the early User Story discussions (who don't capitalize it, generally)
Google tells us that the phrase "acceptance criteria" shows up on this page (https://en.wikibooks.org/wiki/RUP_-_IBM_Rational_Unified_Process/Phases) more than the entire c2.com wiki.
I'm a semantics nut, so I've come to use each phrase very carefully and deliberately:
1. "Conditions of satisfaction": sometimes users and business stakeholders express specific conditions which must be satisfied. The back of a story card is a logical place to capture those expressions with brief notes.
2. "Acceptance Tests": automated tests which prove the desired UI behaviour
3. "Acceptance Criteria": a phrase borne from development methods in which design, implementation, and testing are segregated either by time, people, or both. As in: before execution begins, let's define the criteria by which the feature shall be tested (many months from now) during UAT phase so that engineers know how their implementation will be deemed acceptable.
I intend to listen to the podcast -- perhaps your perspective complements my own.