Welke uitzonderingen moeten afgevangen zijn? En hoe weten marketing, sales, product en development dat het resultaat bijdraagt aan groei?
Daarvoor heb je heldere acceptatiecriteria nodig. Goede acceptatiecriteria bij een user story maken werk toetsbaar, verminderen ruis en zorgen dat teams sneller kunnen bouwen, testen en leren. Zeker in B2B-groei-projecten, waar websiteverbeteringen, campagnes, automatiseringen en salesprocessen samenkomen, voorkom je hiermee dat iedereen een ander beeld heeft van hetzelfde werk.
In dit artikel lees je hoe je acceptatiecriteria voor user stories scherp opschrijft, welke formats handig zijn en hoe je voorkomt dat criteria veranderen in een vage takenlijst.
Wat zijn acceptatiecriteria bij een user story?
Acceptatiecriteria zijn concrete voorwaarden waaraan een user story moet voldoen voordat deze geaccepteerd kan worden. Ze beschrijven niet alleen wat er gebouwd of uitgevoerd moet worden, maar vooral welk gedrag, welke uitkomst of welke kwaliteit aantoonbaar aanwezig moet zijn.
Een user story geeft richting. Acceptatiecriteria maken die richting testbaar.
Bijvoorbeeld:
Als marketingmanager wil ik dat leads uit een LinkedIn-campagne automatisch met de juiste broninformatie worden geregistreerd, zodat sales sneller kan opvolgen en we de kwaliteit van campagnes kunnen vergelijken.
Zonder acceptatiecriteria klinkt dit logisch, maar blijft er veel open. Wat is “de juiste broninformatie”? Waar moet de lead terechtkomen? Welke foutmeldingen zijn acceptabel? Wanneer is sales geïnformeerd? Welke data moet meetbaar zijn?
Acceptatiecriteria beantwoorden dat soort vragen vooraf. Daardoor worden user stories niet alleen bruikbaar voor softwareteams, maar ook voor growth teams, marketeers, sales en directieleden die sneller resultaat willen zonder steeds opnieuw af te stemmen.
Wil je eerst de basis scherp hebben, dan helpt het om terug te gaan naar wat een user story precies is en waarom de formulering altijd moet starten bij gebruiker, context en waarde.
Waarom heldere acceptatiecriteria zoveel verschil maken
Vage user stories leiden tot vage oplevering. Dat klinkt logisch, maar in veel B2B-teams gebeurt het dagelijks. Een sales automation “moet live”, een landingspagina “moet converteren” of een dashboard “moet inzicht geven”. Pas bij oplevering blijkt dat stakeholders iets anders bedoelden.
Heldere acceptatiecriteria helpen op vijf manieren.
Ten eerste verkorten ze feedbackrondes. Als vooraf duidelijk is wat geaccepteerd wordt, hoeft een team minder vaak terug naar de tekentafel. Dat bespaart tijd bij marketeers, developers, sales en management.
Ten tweede verbeteren ze prioritering. Een story met scherpe criteria laat sneller zien of het werk klein genoeg is, of juist te groot voor één sprint of groeiexperiment. Dat maakt een roadmap realistischer.
Ten derde verhogen ze de kwaliteit van testen. Criteria vertalen verwachtingen naar controleerbare scenario’s. Je test dus niet alleen of iets “werkt”, maar of het werkt voor de bedoelde gebruiker in de bedoelde situatie.
Ten vierde maken ze groei beter meetbaar. In growth marketing is “klaar” zelden genoeg. Je wilt weten of een wijziging effect heeft op leadkwaliteit, conversie, opvolging of learning velocity. Acceptatiecriteria kunnen daarom ook tracking, data en rapportagevoorwaarden bevatten.
Ten vijfde verminderen ze afhankelijkheid van losse aannames. Dat is belangrijk voor organisaties die minder willen leunen op toeval, bestaande netwerken of ad-hoc verkoopactiviteiten, en juist willen bouwen aan een voorspelbaarder groeiproces.
Acceptatiecriteria, Definition of Done en taken: wat is het verschil?
Acceptatiecriteria worden vaak verward met een Definition of Done of met losse taken. Dat zorgt voor ruis. Het verschil is simpel: acceptatiecriteria horen bij één specifieke user story, terwijl de Definition of Done meestal voor al het werk geldt. Taken beschrijven wat het team doet om de story te realiseren.
| Onderdeel | Beantwoordt de vraag | Voorbeeld |
|---|---|---|
| User story | Voor wie doen we dit en waarom? | Als inkoper wil ik snel productspecificaties kunnen aanvragen, zodat ik leveranciers beter kan vergelijken. |
| Acceptatiecriteria | Wanneer accepteren we deze specifieke story? | De aanvraag bevat productcategorie, bedrijfsnaam en zakelijke e-mail, en wordt zichtbaar geregistreerd met broninformatie. |
| Definition of Done | Welke kwaliteitsafspraken gelden altijd? | De oplossing is getest, relevante documentatie is bijgewerkt en stakeholders hebben de review gezien. |
| Taken | Wat moet het team uitvoeren? | Formulier ontwerpen, validatie instellen, opvolgmail schrijven en tracking controleren. |
Een praktisch ezelsbruggetje: als het criterium alleen geldt voor deze story, is het waarschijnlijk een acceptatiecriterium. Als het voor elk project of elke sprint geldt, hoort het eerder in de Definition of Done.
Waar goede acceptatiecriteria aan voldoen
Goede acceptatiecriteria zijn specifiek genoeg om te testen, maar niet zo gedetailleerd dat ze de oplossing onnodig voorschrijven. Ze geven vrijheid in de uitvoering, terwijl ze duidelijk maken wat wel en niet geaccepteerd wordt.
Een sterk criterium voldoet meestal aan deze kenmerken:
- Toetsbaar: iemand kan objectief controleren of het criterium waar of niet waar is.
- Gebruikersgericht: het criterium beschrijft gedrag of waarde vanuit de context van de gebruiker.
- Afgebakend: het criterium voorkomt dat de story ongemerkt groter wordt.
- Eenduidig: woorden als “snel”, “goed”, “duidelijk” of “gebruiksvriendelijk” zijn concreet gemaakt.
- Relevant voor groei: bij marketing, sales en innovatie is duidelijk welke data, opvolging of conversiestap geraakt wordt.
- Niet te technisch: het criterium schrijft alleen technische details voor als die noodzakelijk zijn voor de waarde of kwaliteit.
Een criterium als “het formulier moet goed werken” is dus te vaag. Een betere variant is: “Wanneer een bezoeker een ongeldig e-mailadres invult, wordt het formulier niet verzonden en verschijnt er een duidelijke foutmelding bij het e-mailveld.”
Dat laatste is testbaar. Je kunt het proberen, beoordelen en accepteren.
Formats om acceptatiecriteria helder op te schrijven
Er is niet één verplicht format. Het beste format hangt af van het type story, de complexiteit en het team dat ermee werkt. Voor B2B-teams zijn vooral deze vier formats praktisch.
1. Checklistcriteria
Dit is het meest toegankelijke format. Je schrijft de criteria als korte, toetsbare voorwaarden. Dit werkt goed voor websites, campagnes, CRM-inrichting, contentflows en eenvoudige automatiseringen.
Voorbeeld:
- Het aanvraagformulier bevat bedrijfsnaam, naam, zakelijke e-mail en hulpvraag.
- Na verzending ziet de bezoeker een bevestiging op dezelfde pagina.
- De aanvraag wordt geregistreerd met campagnebron en pagina-url.
- Sales ontvangt de aanvraag via het afgesproken opvolgkanaal.
- Bij een ontbrekend verplicht veld verschijnt een foutmelding naast dat veld.
Checklistcriteria zijn snel te lezen en goed te gebruiken in refinement, review en acceptatie. Het risico is dat ze te veel op taken gaan lijken. Schrijf daarom altijd vanuit het gewenste resultaat, niet vanuit de interne werkzaamheden.
2. Given-When-Then
Het Given-When-Then-format komt uit behavior-driven development en is vooral handig wanneer gedrag afhankelijk is van een bepaalde situatie. Het dwingt je om context, actie en uitkomst expliciet te maken. De Gherkin-referentie van Cucumber is een bekende bron voor dit type scenariodenken.
Voorbeeld:
| Stap | Voorbeeld |
|---|---|
| Given | Gegeven dat een bezoeker op de demo-pagina staat |
| When | Wanneer de bezoeker het formulier invult met geldige gegevens en op verzenden klikt |
| Then | Dan ziet de bezoeker een bevestiging en wordt de aanvraag geregistreerd met broninformatie |
Dit format is vooral sterk bij formulieren, automatiseringen, toegangsrechten, foutscenario’s en beslisregels. Voor simpele stories kan het wat zwaar voelen. Gebruik het dan alleen voor de belangrijkste scenario’s.
3. Regel plus voorbeeld
Sommige user stories draaien om businessregels. Denk aan lead scoring, segmentatie, e-mailflows, prijsaanvragen of klantkwalificatie. Dan helpt het om eerst de regel te beschrijven en daarna een concreet voorbeeld te geven.
Voorbeeld:
| Regel | Voorbeeld |
|---|---|
| Een lead wordt als sales qualified gemarkeerd wanneer het bedrijf binnen de gekozen ICP valt en er een concrete aanvraag is gedaan. | Een operations manager van een productiebedrijf vraagt een demo aan voor drie vestigingen. De lead krijgt status sales qualified. |
| Een lead wordt niet als sales qualified gemarkeerd wanneer alleen een student of leverancier informatie aanvraagt. | Een student vraagt een whitepaper aan via een privé-mailadres. De lead krijgt geen sales qualified status. |
Dit voorkomt interpretatieverschillen tussen marketing en sales. Zeker bij een slecht presterende commerciële funnel zit het probleem vaak niet alleen in volume, maar in onduidelijke definities van kwaliteit.
4. Meetcriteria voor groei-experimenten
Bij growth marketing is een user story vaak gekoppeld aan een hypothese. Dan zijn acceptatiecriteria pas compleet als ook duidelijk is wat gemeten wordt.
Voorbeeld:
Als technisch directeur wil ik direct kunnen zien of een oplossing past bij mijn branche, zodat ik sneller bepaal of een gesprek relevant is.
Mogelijke acceptatiecriteria:
- De pagina bevat minimaal drie herkenbare branchesituaties voor de gekozen doelgroep.
- Elke situatie linkt naar een relevante vervolgstap, zoals een aanvraag of verdiepend bewijs.
- Klikken op de vervolgstap worden meetbaar geregistreerd.
- Na publicatie is zichtbaar hoeveel bezoekers de sectie bekijken en hoeveel doorklikken.
Let op: acceptatiecriteria zijn geen garantie op groei. Ze zorgen wel dat het experiment netjes live staat en leerbaar is. Het resultaat zelf moet je daarna analyseren.
Voorbeeld: van vaag naar scherp
Stel dat een B2B-bedrijf meer demo-aanvragen wil via de website. De user story luidt:
Als operations manager wil ik snel een demo kunnen aanvragen zonder veel verplichte velden, zodat ik makkelijk kan onderzoeken of de oplossing past bij mijn organisatie.
Een vage versie van acceptatiecriteria zou kunnen zijn: “Het formulier is kort, werkt goed en stuurt leads door naar sales.” Dat klinkt redelijk, maar is onvoldoende om betrouwbaar op te leveren.
| Vage formulering | Waarom dit zwak is | Heldere acceptatiecriteria |
|---|---|---|
| Het formulier is kort. | “Kort” is subjectief. | Het formulier bevat maximaal vier verplichte velden: naam, zakelijke e-mail, bedrijfsnaam en hulpvraag. |
| Het formulier werkt goed. | Niet duidelijk wat getest moet worden. | Bij geldige invoer wordt het formulier verzonden en ziet de bezoeker binnen dezelfde sessie een bevestiging. |
| Leads gaan naar sales. | Geen kanaal, inhoud of timing afgesproken. | De aanvraag wordt doorgestuurd naar het afgesproken saleskanaal met naam, bedrijfsnaam, e-mail, hulpvraag en bronpagina. |
| Fouten worden netjes afgehandeld. | “Netjes” is niet toetsbaar. | Bij ontbrekende verplichte velden verschijnt per veld een foutmelding en blijft de ingevulde informatie behouden. |
| Marketing kan meten wat het oplevert. | Niet duidelijk welke meting nodig is. | Een succesvolle verzending wordt meetbaar vastgelegd met bron, campagne en pagina-url. |
Met deze criteria kan een team bouwen, testen en accepteren zonder veel interpretatie. Bovendien sluit de story aan op een concreet groeidoel: meer en betere aanvragen met minder frictie.
Wie meer voorbeeldcontext zoekt, kan ook kijken naar een volledig Scrum user story voorbeeld met acceptatiecriteria. Voor marketing- en salesteams zijn daarnaast praktische user story voorbeelden voor marketing en sales nuttig om verschillende formats te vergelijken.
Zo schrijf je acceptatiecriteria stap voor stap
Begin niet bij het systeem of de oplossing, maar bij de waarde. Een goede vraag is: “Wat moet waar zijn zodat deze gebruiker geholpen is en wij dit werk kunnen accepteren?”
Een praktische werkwijze ziet er zo uit:
- Herhaal de user story hardop: Controleer of gebruiker, behoefte en waarde scherp genoeg zijn voordat je criteria schrijft.
- Bepaal de normale situatie: Beschrijf eerst wat er gebeurt wanneer alles goed gaat.
- Voeg uitzonderingen toe: Denk aan ontbrekende invoer, verkeerde data, niet-passende leads of onduidelijke keuzes.
- Maak vage woorden concreet: Vervang “snel”, “duidelijk” en “goed” door observeerbare voorwaarden.
- Controleer meetbaarheid: Bepaal of data, tracking of opvolging nodig is om de waarde achteraf te beoordelen.
- Laat de juiste mensen meelezen: Betrek minimaal de eigenaar van de waarde en de mensen die het werk uitvoeren of opvolgen.
Voor B2B-groeiteams is vooral stap vijf belangrijk. Een landingspagina kan technisch correct zijn, maar nog steeds weinig opleveren als je niet meet waar bezoekers afhaken. Een leadflow kan live staan, maar weinig waarde hebben als sales niet ziet waar de lead vandaan komt of waarom die relevant is.
Veelgemaakte fouten bij acceptatiecriteria
De eerste fout is acceptatiecriteria pas achteraf schrijven. Dan worden ze vaak gebruikt om een al gekozen oplossing te rechtvaardigen, in plaats van om vooraf alignment te creëren. Schrijf ze daarom tijdens refinement of voorbereiding, niet pas tijdens review.
De tweede fout is criteria verwarren met taken. “Button ontwerpen”, “automation bouwen” of “copy schrijven” zijn werkzaamheden. Acceptatiecriteria beschrijven wat er na die werkzaamheden waar moet zijn. Het verschil lijkt klein, maar het verandert de manier waarop teams denken.
De derde fout is te veel criteria toevoegen. Als een user story vijftien criteria nodig heeft, is de story waarschijnlijk te groot. Splits het werk dan op in kleinere stories of maak eerst een epic met losse deelstories. Dat houdt uitvoering sneller en feedback concreter.
De vierde fout is geen negatieve scenario’s beschrijven. Vooral in B2B-processen zijn uitzonderingen belangrijk. Denk aan leads buiten de doelgroep, dubbele aanvragen, ontbrekende bedrijfsinformatie of gebruikers die nog niet klaar zijn voor salescontact.
De vijfde fout is geen afspraak maken over acceptatie. Wie mag zeggen dat het werk klaar is? Marketing? Sales? Product? De directie? Zonder eigenaar blijft acceptatie politiek of persoonlijk. Met duidelijke criteria wordt het inhoudelijk.
Voorbeelden voor marketing, sales en innovatie
Acceptatiecriteria zijn niet alleen nuttig voor softwareontwikkeling. Juist in growth marketing en innovatie helpen ze om ideeën sneller uitvoerbaar te maken.
| Type user story | Mogelijk acceptatiecriterium |
|---|---|
| Landingspagina | De primaire call-to-action is zichtbaar boven de vouw op desktop en mobiel. |
| LinkedIn leadgeneratie | Elke nieuwe lead wordt vastgelegd met campagne, doelgroepsegment en eerste interactie. |
| E-mailcampagne | Een contact ontvangt geen opvolgmail wanneer het zich heeft afgemeld of niet binnen het segment valt. |
| Contentmarketing | Het artikel bevat een duidelijke vervolgstap die past bij de zoekintentie van de lezer. |
| Conversieoptimalisatie | Het experiment heeft vooraf één primaire conversiemaatstaf en één beslismoment. |
| Salesopvolging | Een inbound aanvraag bevat voldoende context voor sales om het eerste gesprek relevant te openen. |
Deze voorbeelden laten zien dat acceptatiecriteria niet alleen over functionaliteit gaan. Ze gaan over bruikbaarheid, meetbaarheid en commerciële relevantie. Dat maakt ze waardevol voor teams die sneller nieuwe klanten willen aantrekken en tegelijk minder tijd willen verliezen aan onduidelijke overdrachten.
Hoe scherp moeten acceptatiecriteria zijn?
De kunst is balans. Te vage criteria leveren discussie op. Te gedetailleerde criteria maken teams traag en inflexibel. Een goed criterium beschrijft wat nodig is om waarde te leveren, zonder elk detail van de oplossing dicht te timmeren.
Vraag jezelf bij elk criterium drie dingen af:
- Kan iemand dit objectief testen?
- Helpt dit criterium om de waarde van de user story te bewaken?
- Is dit criterium nodig voor acceptatie, of is het eigenlijk een taak of voorkeur?
Als het antwoord op de eerste twee vragen “ja” is, is het criterium waarschijnlijk waardevol. Als het vooral een persoonlijke voorkeur is, hoort het misschien niet in de acceptatiecriteria thuis.
Een goede vuistregel: drie tot zeven acceptatiecriteria per user story is vaak genoeg. Minder kan bij simpele stories. Meer kan bij complexe businessregels, maar dan moet je kritisch kijken of de story niet opgesplitst moet worden.
Template voor acceptatiecriteria
Gebruik dit eenvoudige template als startpunt in je refinement, sprintplanning of groeioverleg.
| Onderdeel | Vraag | Invulling |
|---|---|---|
| Normaal scenario | Wat gebeurt er als de gebruiker de gewenste actie uitvoert? | Wanneer de gebruiker X doet, gebeurt Y. |
| Verplichte informatie | Welke gegevens of voorwaarden zijn minimaal nodig? | X, Y en Z zijn aanwezig of ingevuld. |
| Uitzonderingen | Wat gebeurt er bij ontbrekende of ongeldige input? | De gebruiker ziet een duidelijke melding en kan corrigeren. |
| Overdracht | Wie of welk team moet iets ontvangen of kunnen opvolgen? | De juiste informatie komt terecht bij de afgesproken eigenaar. |
| Meetbaarheid | Welke data is nodig om effect of kwaliteit te beoordelen? | De actie wordt meetbaar geregistreerd met relevante context. |
| Acceptatie | Wie beoordeelt of de story voldoet? | De verantwoordelijke stakeholder accepteert op basis van deze criteria. |
Je hoeft niet elk onderdeel altijd te gebruiken. Voor een simpele contentaanpassing is meetbaarheid misschien voldoende. Voor een sales automation of leadkwalificatieproces zijn uitzonderingen en overdracht juist cruciaal.
Veelgestelde vragen over acceptatiecriteria voor user stories:
Wat zijn acceptatiecriteria bij een user story? Acceptatiecriteria zijn concrete voorwaarden waaraan een user story moet voldoen voordat deze geaccepteerd wordt. Ze maken duidelijk welk gedrag, welke uitkomst of welke kwaliteit minimaal aanwezig moet zijn.
Hoeveel acceptatiecriteria heeft een user story nodig? Vaak zijn drie tot zeven criteria genoeg. Als je veel meer criteria nodig hebt, is de user story waarschijnlijk te groot of bevat deze meerdere deelproblemen.
Wat is het verschil tussen acceptatiecriteria en Definition of Done? Acceptatiecriteria gelden voor één specifieke user story. De Definition of Done bevat algemene kwaliteitsafspraken die voor bijna al het werk gelden, zoals testen, review en documentatie.
Moet je altijd Given-When-Then gebruiken? Nee. Given-When-Then is handig bij scenario’s, uitzonderingen en businessregels, maar een duidelijke checklist werkt vaak beter voor eenvoudige marketing-, sales- of website stories.
Kunnen acceptatiecriteria ook gebruikt worden buiten softwareontwikkeling? Ja. Ze zijn zeer bruikbaar voor B2B-marketing, salesprocessen, automatisering, content, conversieoptimalisatie en innovatie. Overal waar teams werk willen opleveren zonder interpretatieverschil, helpen acceptatiecriteria.
Maak groeiwerk concreet en testbaar
Heldere acceptatiecriteria maken user stories sterker, maar vooral maken ze teams sneller. Minder discussie, minder herstelwerk en meer focus op wat aantoonbaar waarde oplevert voor klant en bedrijf.
Werk je aan groei, marketing automation, leadgeneratie, conversieoptimalisatie of innovatie, dan is dit geen administratieve oefening. Het is een manier om commerciële ideeën sneller te vertalen naar uitvoerbaar werk en betere beslissingen.
Wil je jouw groeiprojecten scherper prioriteren en sneller live brengen? User Story helpt B2B-bedrijven met strategie én uitvoering op het snijvlak van growth marketing, innovatie en automatisering.
