Given, When, Then: Writing Acceptance Criteria and Definition of Done | SF Vibe Lab S17

The developer says it's done. The client says it's not what they wanted. Who's right? Usually neither, because nobody defined what "done" means. Guest instructor Rodrigo Rosas teaches this class. He's a business analyst, co-founder of the Salesforce Educators Network, and a former full-stack developer who became the "accidental admin" of a university's Salesforce org in Veracruz. The session picks up where S16's user stories left off. It uses one realistic requirement for the whole class: sales reps want to stop duplicate accounts without blocking real new customers. Rodrigo shows why "Salesforce should detect duplicates correctly" is a weak acceptance criterion and rewrites it in Given / When / Then form. He asks students what a "normalized name" is (is "ACME LTD" with two spaces a duplicate?) and walks through three test cases: same name and country, same name in a different country, and cancelling the warning. Students then critique three user stories. One is too vague to test ("keep accounts clean"), one is already solutioning ("I want a validation rule"), and one is missing what happens after the warning. Along the way he explains why he prefers eliciting requirements over gathering them, and his cat makes a brief appearance. Next comes the Definition of Done: how it differs from acceptance criteria (story-specific vs. a team-wide quality bar), and Edgar Cambranes' challenge to the software engineering students to say where each one fits in the development process. In the AI critic lab, Rodrigo runs a tightly scoped prompt in ChatGPT, reviews the drafted criteria live and checks them against an inspection checklist. The rule: AI proposes, the team decides. The last half-hour is Q&A: front end or back end first, what to do when acceptance criteria change mid-project (and why billable hours matter), how a beginner can tell an assumption from a confirmed business rule, and how to handle a client who's asking for the wrong thing ("two gallons of empathy," and sometimes a Ferrari when they needed a Volkswagen). Session 17 of 23 from SF Vibe Lab at Universidad Autónoma de Yucatán. Chapters 00:00 Nobody defined what "done" means 01:02 Rodrigo Rosas: from accidental admin to business analyst 04:31 Picking up from user stories: today's two questions 06:04 Recap: the user story format 08:24 The requirement: prevent duplicates without blocking real customers 10:00 A quick user story: what's missing? 12:40 What acceptance criteria are: Given / When / Then 14:46 Weak vs. stronger acceptance criteria 16:55 What's a "normalized name"? 20:58 Three test cases: warning, different country, cancel 23:15 Given / When / Then isn't automatically enough 26:51 Exercise: critique three user stories 28:53 Story 2: "I want a validation rule" is already solutioning 31:53 Story 3: a warning, but then what? 33:43 Questions to ask before writing criteria 35:19 Eliciting vs. gathering requirements 38:47 What is the Definition of Done? 41:20 Acceptance criteria vs. Definition of Done 43:05 Story-specific criteria vs. a team DoD checklist 44:18 Edgar's question: where do AC and DoD fit in the process? 50:23 Agile, AI and working on real teams 54:44 AC tests the story; DoD comes after 57:35 AI critic lab: a prompt for drafting acceptance criteria 1:00:00 Live in ChatGPT: reviewing the AI's draft 1:02:17 AI output inspection checklist 1:04:17 Wrap-up: don't assume, ask 1:07:38 Q&A: front end or back end first? 1:10:17 Business analysis works outside software too 1:12:13 Q&A: when acceptance criteria change mid-project 1:17:23 Karen's take: renegotiating scope 1:19:47 Billable hours and work culture 1:22:04 Q&A: assumption or confirmed business rule? 1:25:54 Q&A: what if the client doesn't know the rule yet? 1:27:49 Q&A: criteria for incomplete data 1:29:32 Q&A: when the client asks for the wrong thing