Requirements & User Stories: Who, What, Why | SF Vibe Lab S16

Guest instructor Adriana Navarro, a business analyst who started her career as a developer, introduces herself and then teaches how to turn discovery notes into clear requirements and user stories. She starts with the difference between the two: a business requirement is a high-level goal ("eliminate manual tracking"), and a user story is an actionable feature an admin or developer can build. Then she covers the golden rule of a user story, the three Ws: who (a specific role, never just "as a user"), what and why. Her examples come from a shelter scenario, with a shelter manager, a donor relations coordinator, a social worker and resident profiles, loosely based on Fraternidad Sin Fronteras, a nonprofit earlier UADY classes worked with. She asks students who writes user stories and who builds them, and shows how developers read a story in Salesforce terms (a role points to profiles and permission sets). There are two hands-on exercises. In the first, students decide whether each statement is a business requirement or a user story. One statement causes a real disagreement: a student argues it has a who, a what and a why, and she explains why it still counts as a requirement. In the second, students separate good stories from ambiguous ones ("faster and better" can't be tested) and find the trap: a story that asks for "a custom medical history object with lookups." That describes the solution, so it isn't a user story. The rule is who, what and why, not how. She then covers who defines and prioritizes stories: the product owner, the dev team and architects, with the business analyst running the session. Her example compares a time-sink AI sentiment-analysis story with a quick-win occupancy alert email. Fredy Colli Yah asks students if they write requirements before they start coding. In the Q&A, Adriana says she uses AI less to write user stories and more to validate them and to draft QA and UAT test scripts. She also explains how she checks stories against business scenarios agreed with users. Fredy asks what happens when a client changes a requirement mid-project. Her answer: it usually comes up in UAT, so ask questions first, decide if it's an enhancement or a training issue, put it in the backlog and prioritize it with the product owner. Along the way, Fredy asks a student on the spot what "UAT" means to show why you should always ask about acronyms. The last ten minutes are in Spanish. Edgar Cambranes asks what Adriana learned moving from developer to business analyst that school didn't teach her. Her answer: ask why, don't stay quiet, and understand the business, because then everything you build makes sense. The class ends with a quick mention of a UADY master's thesis on using AI to rate user story quality. Session 16 of 23 from SF Vibe Lab at Universidad Autónoma de Yucatán. Chapters 00:00 Adriana Navarro introduces herself 02:55 Turning discovery notes into user stories 03:44 Quick check: requirements or user stories in your projects? 05:11 Business requirement vs. user story 06:53 The golden rule: who, what, why 08:53 What happens if you drop the "why"? 11:29 Who writes user stories, and who builds them? 15:45 How developers read a user story in Salesforce 19:50 Requirement vs. user story: student answers 21:34 Why is this statement ambiguous? 25:55 Exercise 1: business requirement or user story? 32:22 In a nutshell: what's the difference? 36:20 Exercise 2: good user story or ambiguous? Find the trap 41:46 The trap: a user story that proposes the solution 48:29 Who defines requirements and who's involved? 51:39 Why prioritize user stories? 55:17 Who prioritizes: product owner, dev team and the BA 1:00:33 Quick wins vs. time sinks 1:04:22 Fredy's question: do you write requirements before code? 1:08:46 Which is easier to build from? 1:09:46 Next up: acceptance criteria 1:10:51 Q&A: how AI has changed the business analyst's job 1:12:52 Q&A: validating user stories with business scenarios 1:15:35 Q&A: when requirements change mid-sprint 1:17:11 What is UAT? Why you should ask about acronyms 1:19:42 Handling change requests found in UAT 1:25:46 Edgar's question (in Spanish): lessons from developer to BA 1:28:50 Adriana's answer: finding the "why" behind the work 1:31:35 Ask questions, be the bridge, know the business 1:34:46 A thesis on AI rating user story quality