Voor B2B-teams is dat extra belangrijk. Of je nu werkt aan een website, marketing automation, een salesproces, een klantportaal of een intern dashboard, vage stories zorgen voor vertraging, herwerk en discussies in de sprint review. Scherpe acceptatiecriteria helpen juist om sneller te bouwen, beter te testen en voorspelbaarder resultaat te leveren.
In dit artikel vind je een compleet voorbeeld, meerdere varianten en een praktisch template dat je direct kunt gebruiken in je eigen backlog.
Wat is een scrum user story met acceptatiecriteria?
Een user story beschrijft kort wat een gebruiker wil bereiken en waarom dat waardevol is. Het klassieke format is:
Als [type gebruiker] wil ik [actie of behoefte], zodat [waarde of resultaat].
In Scrum zijn user stories geen verplicht onderdeel van de officiële Scrum Guide. De Scrum Guide spreekt vooral over Product Backlog Items. User stories zijn wel een veelgebruikte en praktische manier om die backlog-items klantgericht te formuleren.
Acceptatiecriteria beschrijven vervolgens waaraan de oplossing moet voldoen voordat de Product Owner de story kan accepteren. Ze maken de story testbaar. Zonder acceptatiecriteria blijft een user story vaak te veel open voor interpretatie.
Wil je eerst de basis scherp krijgen, dan helpt deze uitleg over wat een user story is voor B2B-teams om het verschil tussen stories, requirements en taken helder te maken.
Compleet scrum user story voorbeeld
Stel: een B2B-bedrijf wil meer grip krijgen op leadopvolging. Websitebezoekers downloaden regelmatig een whitepaper, maar sales volgt leads te laat of helemaal niet op. Het team wil daarom een automatische opvolgmail toevoegen aan het proces.
User story:
Als marketingmanager wil ik dat een websitebezoeker na het downloaden van een whitepaper automatisch een relevante opvolgmail ontvangt, zodat warme leads sneller worden opgevolgd en de kans op een salesgesprek stijgt.
Deze story is sterker dan “automatische e-mail bouwen”, omdat duidelijk is wie de behoefte heeft, wat er moet gebeuren en waarom het commercieel belangrijk is. De waarde zit niet in de e-mail zelf, maar in snellere opvolging en meer kans op kwalitatieve leads.
Acceptatiecriteria bij dit voorbeeld
Een praktische manier om acceptatiecriteria te formuleren is het Given, When, Then-format. In het Nederlands kun je dat vertalen naar Gegeven, Wanneer, Dan.
| Acceptatiecriterium | Gegeven | Wanneer | Dan |
|---|---|---|---|
| 1. Automatische verzending | Een bezoeker vult het whitepaperformulier correct in | Het formulier succesvol wordt verzonden | De bezoeker ontvangt binnen 5 minuten een opvolgmail |
| 2. Relevante inhoud | De bezoeker downloadt whitepaper A | De opvolgmail wordt verzonden | De inhoud van de e-mail verwijst naar whitepaper A en bevat een passende vervolgstap |
| 3. Interne notificatie | Een lead heeft een zakelijk e-mailadres ingevuld | De download is geregistreerd | Sales ontvangt een notificatie met naam, bedrijf en gedownloade content |
| 4. Geen dubbele e-mails | Dezelfde bezoeker downloadt binnen 24 uur hetzelfde document opnieuw | Het formulier opnieuw wordt verzonden | Er wordt geen tweede identieke opvolgmail verstuurd |
| 5. Meetbaarheid | De opvolgmail is verzonden | De ontvanger opent of klikt in de e-mail | Open- en klikdata worden correct geregistreerd in het marketingplatform |
Deze acceptatiecriteria zijn concreet, controleerbaar en gekoppeld aan gedrag. Een developer, marketeer, tester en Product Owner kunnen hiermee hetzelfde beeld vormen van wat er moet worden opgeleverd.
Waarom dit een sterk scrum user story voorbeeld is
Een goede user story voorkomt dat een sprint gevuld raakt met losse taken zonder duidelijke impact. In dit voorbeeld is de commerciële context helder: het team wil sneller opvolgen, minder handmatig werk doen en meer rendement halen uit bestaande websitebezoekers.
De acceptatiecriteria zorgen voor focus. Het team hoeft niet te discussiëren over alle mogelijke marketing automation-scenario’s. Voor deze sprint gaat het om één download, één opvolgmail, één notificatie en meetbare interactie. Dat is klein genoeg om te bouwen en waardevol genoeg om te testen.
Dit sluit goed aan bij het INVEST-principe, een bekende kwaliteitscheck voor user stories. Een goede story is idealiter onafhankelijk, onderhandelbaar, waardevol, inschatbaar, klein en testbaar. Vooral dat laatste punt wordt vaak vergeten. Acceptatiecriteria maken een story testbaar en daarmee veel bruikbaarder in Scrum.
Verschil tussen user story, acceptatiecriteria en Definition of Done
Teams halen deze begrippen vaak door elkaar. Dat leidt tot misverstanden tijdens planning, development en review. De verschillen zijn belangrijk.
| Begrip | Doel | Voorbeeld |
|---|---|---|
| User story | Beschrijft de behoefte en waarde voor de gebruiker | Als salesmanager wil ik nieuwe leads prioriteren, zodat mijn team sneller de beste kansen opvolgt |
| Acceptatiecriteria | Beschrijven wanneer deze specifieke story geaccepteerd wordt | Leads met een score boven 80 worden gemarkeerd als high priority |
| Definition of Done | Beschrijft de algemene kwaliteitslat voor alle opgeleverde items | Code is gereviewd, getest, gedocumenteerd en live gezet volgens teamafspraken |
De user story vertelt dus waarom iets nodig is. De acceptatiecriteria vertellen wat er minimaal moet kloppen voor deze story. De Definition of Done bewaakt de algemene kwaliteit van het werk.
Extra voorbeelden van scrum user stories met acceptatiecriteria
Onderstaande voorbeelden zijn geschreven voor B2B-teams die werken aan groei, sales, marketing en digitale processen. Gebruik ze als inspiratie, maar pas altijd de gebruiker, context en criteria aan je eigen situatie aan.
Voorbeeld 1: leadformulier optimaliseren
User story:
Als potentiële klant wil ik snel een aanvraagformulier kunnen invullen zonder onnodige velden, zodat ik makkelijk contact kan opnemen en niet afhaak.
| Acceptatiecriterium | Omschrijving |
|---|---|
| Verplichte velden | Alleen naam, zakelijk e-mailadres, bedrijfsnaam en vraag zijn verplicht |
| Validatie | Een foutmelding verschijnt direct als een e-mailadres ongeldig is |
| Conversiemeting | Elke succesvolle formulierinzending wordt als conversie geregistreerd |
| Bevestiging | De bezoeker ziet na verzending een duidelijke bevestigingspagina |
Voorbeeld 2: lead scoring voor salesprioriteit
User story:
Als salesmanager wil ik leads automatisch kunnen prioriteren op basis van gedrag en profiel, zodat mijn team eerst de meest kansrijke leads opvolgt.
| Acceptatiecriterium | Omschrijving |
|---|---|
| Score op gedrag | Een demo-aanvraag levert meer punten op dan een nieuwsbriefinschrijving |
| Score op profiel | Leads met een zakelijk domein krijgen een hogere score dan generieke e-mailadressen |
| Drempelwaarde | Leads boven de afgesproken score worden gemarkeerd als sales qualified |
| Notificatie | Sales ontvangt automatisch een melding bij een nieuwe sales qualified lead |
Voorbeeld 3: dashboard voor marketingprestaties
User story:
Als marketingmanager wil ik per kanaal kunnen zien hoeveel kwalitatieve leads er binnenkomen, zodat ik budget kan verschuiven naar de best presterende campagnes.
| Acceptatiecriterium | Omschrijving |
|---|---|
| Kanaaloverzicht | Het dashboard toont leads per kanaal, zoals organisch, betaald, e-mail en LinkedIn |
| Kwaliteitsfilter | Leads kunnen worden gefilterd op status of leadscore |
| Periodekeuze | De gebruiker kan data bekijken per week, maand en kwartaal |
| Export | De data kan worden geëxporteerd voor rapportage aan directie of management |
Voorbeeld 4: LinkedIn-campagne opvolgen
User story:
Als business developer wil ik automatisch kunnen zien welke LinkedIn-leads interactie hebben gehad met onze content, zodat ik mijn opvolging persoonlijker en relevanter kan maken.
| Acceptatiecriterium | Omschrijving |
|---|---|
| Interactieregistratie | Kliks op campagnelinks worden gekoppeld aan de juiste campagne |
| Segmentatie | Leads kunnen worden gegroepeerd op branche, functietitel of campagnethema |
| Opvolgactie | Leads met meerdere interacties komen in een aparte opvolglijst |
| Privacy | Alleen toegestane en beschikbare gegevens worden verwerkt volgens interne afspraken |
Voorbeeld 5: offerteaanvraag verbeteren
User story:
Als inkoper wil ik bij een offerteaanvraag meteen de belangrijkste specificaties kunnen doorgeven, zodat ik sneller een passende reactie ontvang.
| Acceptatiecriterium | Omschrijving |
|---|---|
| Relevante velden | Het formulier bevat velden voor toepassing, gewenste hoeveelheid, deadline en contactgegevens |
| Uploadmogelijkheid | De gebruiker kan een document of technische specificatie toevoegen |
| Interne routing | De aanvraag wordt doorgestuurd naar de juiste afdeling op basis van productcategorie |
| Bevestigingsmail | De aanvrager ontvangt een bevestiging met samenvatting van de aanvraag |
Zo schrijf je betere acceptatiecriteria
Acceptatiecriteria moeten niet alles beschrijven wat een team moet doen. Ze moeten vooral duidelijk maken welk gedrag, welke uitkomst of welke kwaliteit nodig is om de user story te accepteren. Houd ze daarom kort, concreet en toetsbaar.
Een goede vuistregel: als je niet objectief kunt controleren of het criterium gehaald is, is het waarschijnlijk te vaag. “Het formulier is gebruiksvriendelijk” klinkt logisch, maar is moeilijk te testen. “Het formulier bevat maximaal vier verplichte velden en toont foutmeldingen direct onder het veld” is veel scherper.
Gebruik deze checklist om acceptatiecriteria te verbeteren:
- Beschrijf zichtbaar gedrag of meetbare uitkomst.
- Vermijd interne implementatietaken als criterium.
- Houd criteria specifiek voor deze user story.
- Stem criteria af met Product Owner, developers en testers.
- Controleer of elk criterium bijdraagt aan de waarde van de story.
Voor teams die structureel betere stories willen formuleren, is het nuttig om ook te kijken naar hoe je user stories schrijft die resultaat opleveren. Dan voorkom je dat acceptatiecriteria een pleister worden op een story die eigenlijk te vaag is.
Template: scrum user story met acceptatiecriteria
Gebruik dit template tijdens backlog refinement of sprint planning. Het dwingt je om de gebruiker, waarde en acceptatie vooraf scherp te maken.
User story:
Als [type gebruiker]
wil ik [actie, behoefte of mogelijkheid]
zodat [waarde, resultaat of reden].
Context:
[Waarom is deze story nu belangrijk? Welk probleem lossen we op?]
Acceptatiecriteria:
1. Gegeven [startsituatie], wanneer [actie], dan [verwachte uitkomst].
2. Gegeven [startsituatie], wanneer [actie], dan [verwachte uitkomst].
3. Gegeven [startsituatie], wanneer [actie], dan [verwachte uitkomst].
Niet inbegrepen in deze story:
[Wat doen we bewust nog niet?]
Meetpunt:
[Hoe weten we na livegang of dit waarde oplevert?]
Het onderdeel “Niet inbegrepen” is belangrijk. Juist in B2B-projecten groeien stories snel uit tot grote wensenlijsten. Door expliciet te maken wat buiten scope valt, blijft de sprint haalbaar en blijft de sterke funnel of salesflow stap voor stap verbeteren.
Wanneer is een user story te groot?
Een user story is te groot als het team hem niet goed kan inschatten, niet binnen één sprint kan opleveren of te veel afhankelijkheden bevat. In dat geval werk je waarschijnlijk met een epic in plaats van een story.
Bijvoorbeeld: “Als marketingmanager wil ik een volledig geautomatiseerde leadgeneratiefunnel” is te breed. Daarin zitten meerdere onderdelen, zoals formulieren, content, e-mails, lead scoring, CRM-koppelingen, rapportage en salesopvolging. Splits zo’n groot onderwerp op in kleinere stories die elk zelfstandig waarde leveren.
Werk je met grotere groeiprojecten, dan helpt het om eerst het verschil tussen thema’s, epics en stories te begrijpen. Dit artikel over epics in groei-projecten laat zien hoe je grote ambities vertaalt naar behapbaar werk.
Veelgemaakte fouten bij scrum user stories
Veel teams gebruiken user stories, maar halen er minder waarde uit dan mogelijk is. Meestal komt dat doordat stories te technisch, te groot of te vaag zijn.
Een eerste fout is dat de story eigenlijk een taak is. “CRM-koppeling bouwen” zegt niets over de gebruiker of waarde. Beter is: “Als salesmedewerker wil ik nieuwe demo-aanvragen automatisch in het CRM zien, zodat ik sneller kan opvolgen zonder handmatig kopiëren.”
Een tweede fout is dat acceptatiecriteria subjectief blijven. Woorden als snel, makkelijk, goed en duidelijk kunnen nuttig zijn in gesprekken, maar moeten worden vertaald naar toetsbare afspraken. Wat betekent snel? Binnen 2 seconden? Binnen 5 minuten? Binnen één werkdag?
Een derde fout is dat teams alleen denken aan oplevering, niet aan resultaat. Zeker bij growth marketing, sales en innovatie is livegang niet het eindpunt. De vraag is of de story bijdraagt aan betere conversie, snellere opvolging, lagere handmatige werklast of een renderende pipeline.
Praktische workflow voor je volgende sprint
Een goede workflow hoeft niet ingewikkeld te zijn. Begin met het probleem dat je wilt oplossen. Schrijf daarna de user story vanuit de gebruiker. Bespreek vervolgens met het team welke acceptatiecriteria nodig zijn om misverstanden te voorkomen. Pas daarna ga je inschatten, plannen en bouwen.
Voor een B2B-team kan een refinement-sessie bijvoorbeeld draaien om één centrale vraag: “Welke kleine verbetering levert deze sprint merkbaar meer grip op leads, conversie of opvolging op?” Die vraag houdt de backlog weg van losse wensen en dichter bij groei.
Leg na oplevering ook vast wat je hebt geleerd. Heeft de nieuwe opvolgmail meer clicks opgeleverd? Worden leads sneller opgevolgd? Vult sales de juiste data aan? Zo wordt Scrum niet alleen een manier om werk te organiseren, maar ook een manier om sneller te leren wat commercieel werkt.
Veelgestelde vragen over scrum user story voorbeelden met acceptatiecriteria:
Wat is een goed scrum user story voorbeeld? Een goed voorbeeld is: “Als marketingmanager wil ik dat een websitebezoeker na het downloaden van een whitepaper automatisch een relevante opvolgmail ontvangt, zodat warme leads sneller worden opgevolgd.” Deze story is concreet, klantgericht en gekoppeld aan bedrijfswaarde.
Wat zijn acceptatiecriteria bij een user story? Acceptatiecriteria zijn voorwaarden waaraan de oplossing moet voldoen voordat de user story wordt geaccepteerd. Ze beschrijven bijvoorbeeld welk gedrag zichtbaar moet zijn, welke data geregistreerd wordt of welke foutmeldingen getoond moeten worden.
Hoeveel acceptatiecriteria heeft een user story nodig? Meestal zijn 3 tot 6 acceptatiecriteria voldoende. Als je er veel meer nodig hebt, is de story mogelijk te groot of bevat hij meerdere losse functionaliteiten.
Moeten acceptatiecriteria technisch zijn? Niet per se. Goede acceptatiecriteria beschrijven vooral de gewenste uitkomst of het gedrag voor de gebruiker. Technische details kunnen nodig zijn, maar ze mogen de gebruikerswaarde niet vervangen.
Wat is het verschil tussen acceptatiecriteria en Definition of Done? Acceptatiecriteria gelden voor één specifieke user story. De Definition of Done geldt voor al het werk van het team en beschrijft de algemene kwaliteitslat, zoals testen, review en documentatie.
Van betere user stories naar snellere groei
User stories zijn pas waardevol als ze helpen om sneller de juiste dingen te bouwen. Voor B2B-teams betekent dat: minder losse taken, minder discussie, minder afhankelijkheid van toeval en meer focus op meetbare groei.
Wil je user stories inzetten voor marketing, sales, automatisering of digitale groei? Dan helpt User Story je om strategie en uitvoering samen te brengen. Van scherpe groeihypotheses tot snelle experimenten en operationele realisatie. Bekijk hoe User Story B2B-bedrijven helpt met growth marketing en innovatie en zet je backlog om in werk dat aantoonbaar bijdraagt aan nieuwe klanten.
