Hoe je uitstekende acceptatiecriteria schrijft (met voorbeelden)
Hoe vaak heb je ontwikkelaars en testers zien discussiëren over de manier waarop een bepaalde functie zou moeten werken? En wat dacht je van de verwarde gezichten van ontwikkelaars die niet zeker wisten hoe ze de door jou gevraagde functie moesten bouwen? Beide zijn vrij veelvoorkomende problemen in de softwarewereld en gelukkig heb je een krachtig hulpmiddel in je arsenaal om ze op te lossen: acceptatiecriteria.
In deze gids leg ik de aard van dit format voor het vastleggen van vereisten uit, bespreek ik hun rol in productmanagement en laat ik zien hoe je goede acceptatiecriteria schrijft.
Inhoudsopgave
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Wat is het doel van het schrijven van acceptatiecriteria?
Hoe zien goed geschreven acceptatiecriteria eruit?
Veelgebruikte formats voor acceptatiecriteria
Wat zijn acceptatiecriteria
(en welke plaats hebben ze binnen Agile/Scrum?)
Binnen de Agile-methodologie is een acceptatiecriterium de kleinste eenheid van een functionele of ontwerpvereiste die Agile-productmanagers (of bedrijfsanalisten) aan hun gebruikersverhalen toevoegen om de verschillende toestanden en het gedrag van de functies die het team van plan is te bouwen duidelijk te communiceren.
Technisch gezien kun je acceptatiecriteria overal gebruiken waar je maar wilt. Traditioneel maken ze echter deel uit van gebruikersverhalen, die onderdelen zijn van Agile-epics.
Om acceptatiecriteria beter te begrijpen, frissen we eerst ons geheugen op, nemen we de elementen in deze hiërarchie door en bekijken we waarvoor elk element wordt gebruikt.
Epics
Epics zijn taken die functionele en niet-functionele vereisten op hoog niveau bevatten voor een grote functie of een groep functies die met elkaar samenhangen. Meestal omvat een epic een volledige gebruikssituatie voor je klanten en bevat deze alle onderliggende functies en functionaliteiten die je moet implementeren om de betreffende gebruikssituatie af te dekken.
Stel je voor dat je deel uitmaakte van het productteam van Spotify en het gebruik van de app wilde uitbreiden door een nieuwe gebruikssituatie toe te voegen voor mensen die onderweg zijn en geen toegang tot internet hebben.
Om deze gebruikssituatie af te dekken, kun je overwegen een nieuwe grote functie toe te voegen met de naam “offline modus voor Spotify”. Deze kan een epic worden in je productbacklog, met daarin alle algemene vereisten om gebruikers naar muziek te laten luisteren wanneer ze geen internetverbinding hebben, evenals verschillende gebruikersverhalen met de vereisten voor specifieke onderdelen van deze functie.
Gebruikersverhalen
Gebruikersverhalen zijn kleiner van omvang en vertegenwoordigen één afzonderlijk onderdeel van de functionaliteit binnen de epic. Het zijn behapbare stukjes werk die het Agile-team zich kan verplichten binnen één iteratie op te leveren.
Een van de belangrijkste kenmerken van een gebruikersverhaal is dat de functionaliteit die deze vertegenwoordigt compleet en potentieel bruikbaar moet zijn.
Als je bijvoorbeeld een onlineapp voor bestandsopslag bouwt en je gebruikers de mogelijkheid wilt geven de bestanden die ze hebben geüpload een andere naam te geven, moet je werk uitvoeren aan de front-end (de gebruikersinterface en gebruikerservaring voor het hernoemen) en aan de back-end (het opslaan van de nieuwe naam).
Om ervoor te zorgen dat de functie compleet en bruikbaar is, moet je beide taken afronden en de onderdelen in de front-end en back-end met elkaar verbinden. Je team zou dit allemaal uitvoeren binnen de scope van één gebruikersverhaal.
Als je alleen het back-endwerk zou uitvoeren, zou de taak daarvoor geen echt gebruikersverhaal zijn, omdat deze een oplevering zou bevatten die niet compleet en bruikbaar is.
Om het ontwikkelteam te laten weten hoe de functie eruit zal zien en hoe deze zich moet gedragen, schrijven producteigenaren acceptatiecriteria voor dat gebruikersverhaal.
Acceptatiecriteria voor gebruikersverhalen
Tot slot hebben we de kleinste onderdelen in de hiërarchie van vereisten voor softwareproducten: acceptatiecriteria. Ze vertegenwoordigen afzonderlijke gebruiksscenario’s van die functionaliteit of stukjes informatie die het engineeringteam belangrijk zal vinden bij het implementeren van het gebruikersverhaal.
In het bovenstaande voorbeeld zou een acceptatiecriterium zijn dat er een tekstveld wordt geopend waarin de naam van het bestand al is ingevuld wanneer de gebruiker op de knop ✏️Hernoemen klikt bij het bestand dat hij of zij heeft geüpload.
Definitie van klaar (ja, deze verschilt van acceptatiecriteria!)
Soms verwarren producteigenaren (vooral degenen die relatief nieuw zijn in deze scrumrol) de definitie van klaar met acceptatiecriteria.
Eerlijk gezegd was het in het begin voor mij ook behoorlijk verwarrend, omdat beide “criteria zijn om te controleren of de functie compleet is.”
Het enige verschil is dat de definitie van klaar volledigheid vertegenwoordigt in termen van de ontwikkelprocessen van het team.
Terwijl de acceptatiecriteria functionele vereisten vertegenwoordigen (hoe de functie eruit moet zien en zich moet gedragen).
Dit betekent dat de definitie van klaar hetzelfde blijft voor alle gebruikersverhalen die het team implementeert, tenzij ze tijdens de retrospectieven besluiten hierin wijzigingen aan te brengen. De acceptatiecriteria zijn daarentegen uniek voor elk gebruikersverhaal, omdat ze uitleggen hoe die functie moet werken.
Opmerking: Met sommige productmanagementtools kun je zowel de definitie van klaar als acceptatiecriteria aan je gebruikersverhalen toevoegen.
Nu we ons herinneren waar epics en gebruikersverhalen over gaan en hoe acceptatiecriteria zich daartoe verhouden, gaan we verder met begrijpen waarom producteigenaren überhaupt acceptatiecriteria schrijven.
Wat is het doel van het schrijven van acceptatiecriteria?
Kan ik gewoon een beschrijving van een gebruikersverhaal schrijven zoals ik dat wil, zonder acceptatiecriteria op te nemen? Wat is eigenlijk het voordeel van het schrijven van acceptatiecriteria?
Natuurlijk kun je je gebruikersverhalen schrijven zoals je wilt. Toch raad ik je aan acceptatiecriteria te gebruiken als manier om je vereisten te formuleren, omdat dit formaat allerlei voordelen biedt. Hier zijn er een paar om te overwegen.
Ze stimuleren gedragsgericht denken
Als je kiest voor het BDD-formaat van acceptatiecriteria (daarover later meer), dan beschrijven je acceptatiecriteria de klantreis wanneer je klanten de betreffende functie gebruiken.
Het mooie van deze aanpak is dat je je denken wegstuurt van droge technische vereisten en de functie vanuit het perspectief van de gebruiker gaat bekijken. Zo kun je visualiseren wat gebruikers ervaren en voelen wanneer ze met je functie werken.
Het komt vaak voor dat de producteigenaar beseft dat de functionaliteit die hij of zij voor ogen had niet de beste is zodra die vanuit het perspectief van de gebruikers wordt bekeken.
Ook ik heb dat meerdere keren meegemaakt. Toen ik bijvoorbeeld vereisten opstelde voor een bewerker voor wiskundige formules (onderdeel van een SaaS-product voor financiële analyse dat we destijds bouwden), wilde ik dat het bewerkingsproces er als volgt uitzag:
- Een bewerkingsknop naast de formule.
- Door op de bewerkingsknop te klikken, zou het formuleveld bewerkbaar worden en zouden de knoppen ✅ Opslaan en ❎ Annuleren worden weergegeven.
- Door op een van beide te klikken, zou de bewerkingsmodus worden verlaten en zou daar, afhankelijk van de keuze van de gebruiker, de opgeslagen nieuwe versie of de oude versie van de formule verschijnen.
Dit gedrag ziet er logisch uit, toch?
Nou, niet totdat ik scenario's begon op te schrijven van analisten die ermee werkten en een aanzienlijke bruikbaarheidsfout ontdekte. Analisten zijn meestal bezig de formule stapsgewijs aan te passen en het berekeningsresultaat te bekijken totdat ze de formule hebben die ze willen.
De manier waarop ik me had voorgesteld dat het bewerken zou werken, zou buitengewoon irritant zijn voor mijn doelgebruikers, omdat ze 20-30 keer achter elkaar de bewerkingsmodus zouden moeten openen en verlaten. Daarom wijzigde ik, zodra ik de fout inzag, snel de acceptatiecriteria en vroeg ik om een formulebewerker te bouwen waarin je in realtime wijzigingen kon aanbrengen.
Ze helpen één bron van waarheid te creëren
Als “beginnend” productmanager was mijn grootste uitdaging het communiceren van productvereisten aan mensen met verschillende beroepen of zelfs aan verschillende teams. Het probleem was dat iedereen de vereisten anders begreep en dat de communicatie tussen hen een onduidelijke chaos werd.
Toen stelde een ervaren productmanager voor dat ik het concept van één bron van waarheid zou toepassen door mijn productvereisten op een zeer duidelijke manier te formuleren (dit is iets waarbij AI bij het verzamelen van vereisten kan helpen), dit met iedereen te communiceren en hen te vragen hun werk uitsluitend te baseren op wat daar geschreven stond.
Het was een enorm succes, omdat iedereen hetzelfde begrip had van hoe de functie moest werken en ze bij meningsverschillen konden teruggrijpen op de vereiste.
Acceptatiecriteria zijn een geweldige manier om één enkele bron van waarheid te creëren, omdat ze de functie op een duidelijke en gemakkelijk leesbare manier beschrijven en een hoge granulariteit hebben (omdat ze alle belangrijke details van de functie moeten bevatten).
Ze verbeteren de kwaliteit van acceptatietests
Voor software-engineers fungeren acceptatiecriteria als de productvereisten die ze volgen bij het bouwen van de functie. Voor je kwaliteitsteam hebben acceptatiecriteria daarentegen een paar extra kenmerken:
Ze helpen bij het prioriteren van testgevallen. Als je softwaretestteam veel testgevallen voor die functie heeft en er niet genoeg tijd is om ze allemaal te doorlopen, zullen ze de testscripts die overeenkomen met de acceptatiecriteria als eerste prioriteren en uitvoeren, omdat deze de meest kritieke gebruikersstromen beschrijven.
Ze dienen als een acceptatiechecklist. Dit punt geldt zowel voor QA-teams als voor producteigenaren die de functie moeten accepteren. Acceptatiecriteria dienen, zoals de naam al aangeeft, als een checklist om te bepalen of de functie geslaagd of mislukt is. Als niet aan een of meer acceptatiecriteria wordt voldaan, zal het QA-team het verhaal heropenen en het engineeringteam vragen de ontbrekende functionaliteit toe te voegen.
Samengevat zijn acceptatiecriteria onmisbare hulpmiddelen voor producteigenaren om productvereisten op de juiste manier te communiceren. Maar hoe schrijf je goede acceptatiecriteria? Daar help ik je hierna mee.
Hoe zien goed geschreven acceptatiecriteria eruit?
De kwaliteit van de acceptatiecriteria die je schrijft, heeft een directe invloed op de kwaliteit van de functies die je team oplevert. Met een duidelijk begrip van wat er gebouwd moet worden en hoe het getest moet worden, zal je team de functie bouwen zoals jij die voor ogen had, met minimale problemen.
Om uit te blinken in het schrijven van acceptatiecriteria, moet je aandacht besteden aan het volgende.
Duidelijkheid
De #1 zonde die een producteigenaar kan begaan, is het schrijven van onduidelijke en vage acceptatiecriteria. Je kunt het idee van een gedeeld begrip wel vergeten wanneer mensen wat je hebt geschreven op meerdere manieren kunnen interpreteren.
Om te laten zien hoeveel verschil dit maakt, geef ik je een voorbeeld.
Wat begreep je uit deze zin? Kun je me vertellen hoe de geldautomaat het kaarttype zal gebruiken om te beslissen of de gebruiker wel of niet moet worden geauthenticeerd? Zal de geldautomaat de gebruiker authenticeren als aan al deze criteria tegelijkertijd wordt voldaan, of is het voldoende om slechts aan één ervan te voldoen?
Als je dit acceptatiecriterium aan je engineers geeft, zullen ze je overspoelen met vragen en vragen om duidelijkere vereisten. Laten we het nu verbeteren.
Ziet er veel beter uit, toch? Met dit acceptatiecriterium hebben we ook de antwoorden gegeven op alle bovenstaande vragen. De geldautomaat moet het kaarttype ondersteunen dat de gebruiker heeft ingevoerd en aan alle drie de criteria moet tegelijkertijd worden voldaan voordat de geldautomaat authenticatie uitvoert.
Pro-tip: Maak je acceptatiecriteria SMART (specifiek, meetbaar, haalbaar, relevant en testbaar). Ja, ik heb de laatste veranderd in testbaar, omdat dit een belangrijk kenmerk is van effectieve acceptatiecriteria.
Leesbaarheid
Naast het vermijden van vaagheid in je acceptatiecriteria, moet je ze ook eenvoudig houden en ingewikkelde termen of complex Engels vermijden.
Ik weet zeker dat je een team van hoogopgeleide supersterren hebt die met gemak de meest ingewikkelde woorden en uitdrukkingen in de Engelse taal kunnen lezen en begrijpen, maar je wilt hun cognitieve vermogen natuurlijk niet verspillen aan het ontcijferen van je teksten.
Dus niet dit.
Maar dit.
Ik neem aan dat je niet eens de moeite hebt genomen om het eerste acceptatiecriterium volledig te lezen, omdat je je tijd en denkkracht niet wilde verspillen!
Dekking van de gevallen
De duivel zit in de details. Soms realiseer je je dat je een vervelende situatie in je functie over het hoofd hebt gezien wanneer je al ver in de ontwikkelingsfase bent en daarvoor een vervolgtak voor verbetering moet openen, of zelfs alles opnieuw moet doen.
Klinkt dat bekend, toch?
Hoe meer situaties je vooraf in je acceptatiecriteria opneemt, hoe kleiner de kans dat je met dat scenario te maken krijgt bij je backlogitems.
Laten we nu naar de onderstaande acceptatiecriteria kijken.
Zie je hier iets vreemds? Op het eerste gezicht is de vereiste duidelijk: je voegt het e-mailadres toe, klikt op verzenden en de persoon krijgt toegang. In werkelijkheid hebben we hier geen rekening gehouden met veel situaties:
- Als het e-mailadres al in de lijst staat van gebruikers die toegang hebben tot het document, moet je misschien een foutmelding tonen waarin je de gebruiker daarop wijst.
- Je stuurt een uitnodigingsmail naar de gebruiker, dus misschien is het de moeite waard om in je gedeelde lijst te tonen of de uitnodiging is geaccepteerd.
- Als de uitnodiging niet is geaccepteerd, is het misschien de moeite waard om een knop “uitnodiging opnieuw verzenden” toe te voegen.
Er zijn ook negatieve situaties waarin je het gedrag van je functie verduidelijkt wanneer iets leeg is of er een fout is opgetreden.
Actief gebruik van visuele hulpmiddelen
Waren de acceptatiecriteria die ik hierboven deelde volledig duidelijk voor je? Toen ik het veld “Mensen en groepen toevoegen” noemde, begreep je toen duidelijk waar het over ging?
Soms zijn woorden niet voldoende om je team duidelijkheid te geven over de vereisten en kun je ze beter laten zien dan vertellen. Laat me deze acceptatiecriteria nu een beetje verbeteren.
Klopt het als ik aanneem dat je gemakkelijk zou hebben begrepen waar ik het over had met deze acceptatiecriteria als je de afbeelding en mijn opmerkingen naast elkaar had bekeken? Ik durf erop te wedden dat dat zo zou zijn.
Daarmee hebben we de “acceptatiecriteria” van acceptatiecriteria behandeld. Laten we nu de verschillende typen en indelingen bespreken die productteams hiervoor gebruiken.
Veelgebruikte indelingen voor acceptatiecriteria
Ik moet eerlijk tegen je zijn. Ik gebruik zelden dezelfde indeling voor al mijn gebruikersverhalen. De reden is dat verschillende indelingen voor acceptatiecriteria geschikt zijn voor verschillende gebruikssituaties en dat het niet altijd een goed idee is om jezelf ertoe te dwingen altijd dezelfde indeling te gebruiken.
Daarom kies ik de indeling op basis van het verhaal en het soort informatie dat ik in de acceptatiecriteria ervan wil opnemen.
Laten we nu enkele veelgebruikte indelingen en de bijbehorende voorbeelden van acceptatiecriteria bekijken.
BDD-indeling
BDD staat voor gedragsgestuurde ontwikkeling en is een raamwerk dat softwareontwikkelaars en leden van productteams aanmoedigt om vereisten te definiëren op basis van de manier waarop eindgebruikers met de functie zullen werken.
Als manier om vereisten te schrijven op basis van gebruikersgedrag volgen de acceptatiecriteria voor BDD deze specifieke sjabloon:
Gegeven: De voorwaarde voor het specifieke scenario van gebruikersgedrag.
Wanneer: De actie die de gebruiker uitvoert.
Dan: Het resultaat van de actie.
Als je dus wilt uitleggen hoe de opnamemogelijkheid van een geldautomaat werkt, zouden je acceptatiecriteria er als volgt uitzien:
Het type acceptatiecriteria met gegeven/wanneer/dan is uitstekend wanneer je binnen je team empathie voor gebruikersbehoeften wilt creëren door de nadruk te leggen op het perspectief van de gebruiker.
Checklistindeling
In tegenstelling tot BDD (ook wel de “scenario-georiënteerde” indeling genoemd), laat deze indeling het perspectief van de eindgebruiker niet zien. In plaats daarvan gaat het meer om het uitleggen van de specifieke regels die de bedrijfslogica van de functie moet volgen (de alternatieve naam voor deze indeling is “regelgeoriënteerd”). Zo zien ze eruit.
Deze indeling past het best wanneer de logica die je wilt uitleggen complex is, omdat je die kunt opsplitsen in meerdere kleine regels die gemakkelijker te begrijpen en te implementeren zijn.
Stroomindeling
Dit is waarschijnlijk de indeling die ik het meest gebruik.
De flowindeling lijkt op de BDD-indeling, omdat deze ook het perspectief van de gebruiker laat zien. In tegenstelling tot BDD legt deze echter geen strikte structuur op (Given/When/Then). Je bent dus vrij om de stappen die de gebruiker neemt op elke gewenste manier te beschrijven.
Zo zou het registratieproces eruitzien met deze indeling.
De flowindeling is de beste optie als je empathie voor gebruikers wilt creëren (net als met BDD), maar niet echt een strikte structuur wilt volgen.
Zorg dat iedereen op één lijn zit met acceptatiecriteria
Acceptatiecriteria zijn krachtige hulpmiddelen voor producteigenaren. Ze stellen hen in staat om één bron van waarheid te creëren en hun teamleden op één lijn te houden met hun visie op die functie.
Abonneer je op onze nieuwsbrief voor meer handleidingen zoals deze en andere geweldige bronnen voor productprofessionals!
