Wat zijn acceptatiecriteria? Voorbeelden en aanbevolen werkwijzen

Acceptatiecriteria bevorderen duidelijke communicatie en helpen bij het definiëren van verwachtingen. Ze beschrijven de specifieke voorwaarden waaraan een functie of userstory moet voldoen om echt compleet te zijn, en worden soms beschouwd als de 'Definitie van Voltooid'.

Wat is het geheim van het bouwen van software die daadwerkelijk resultaat oplevert? Als je een productmanager of producteigenaar bent, is het beheersen van acceptatiecriteria cruciaal voor het bouwen van functies die doel treffen.

Zonder duidelijke acceptatiecriteria lopen teams het risico op verwarring, gemiste doelen en verspilde moeite. Maar wat zijn acceptatiecriteria precies, en hoe schrijf je ze goed?

In dit artikel leggen we uit wat acceptatiecriteria zijn, geven we voorbeelden uit de praktijk, laten we zien hoe ze verschillen van userstories, waarom ze belangrijk zijn voor je ontwikkelproces en hoe je je eigen criteria schrijft.

Wat zijn acceptatiecriteria?

Acceptatiecriteria zijn de voorwaarden waaraan een product, userstory of werkproces moet voldoen om als compleet te worden beschouwd. Het zijn duidelijke, beknopte en toetsbare verklaringen die gericht zijn op het behalen van positieve klantresultaten.

In plaats van te focussen op hoe je een oplossing bereikt, zijn acceptatiecriteria de uiteindelijke gewenste uitkomst van de taak.

Ze worden gezien als vooraf gedefinieerde vereisten in Agile methodologieën, specifiek een userstory moet hieraan voldoen om als compleet te worden beschouwd. Ze werken ook als een soort Agile requirementsdocumentatie die bepaalde voorwaarden schetst die moeten worden vervuld voor een succesvolle oplevering.

Acceptatiecriteria versus userstory

Acceptatiecriteria en userstories worden vaak samen besproken, maar ze spelen fundamenteel verschillende rollen in productontwikkeling. Het begrijpen van dit onderscheid is cruciaal voor het schrijven van een backlog die zowel gebruikersgericht als leveringsklaar is.

• Userstories formuleren het 'waarom' en communiceren het doel en de waarde van een functie vanuit het perspectief van de gebruiker.

• Acceptatiecriteria definiëren 'hoe succes eruitziet' en vertalen dat doel naar expliciete, verifieerbare vereisten voor implementatie.

Een goed opgestelde userstory legt de klantbehoefte, het beoogde gedrag en de onderliggende motivatie vast. Deze framing verankert backlog-items in echte gebruikerswaarde en biedt essentiële context voor het wegwerken van backlogs en prioritering.

Userstories kunnen bijvoorbeeld zijn:

• Als klant wil ik producten op naam kunnen zoeken, zodat ik gemakkelijk kan vinden wat ik zoek.

Deze story geeft richting. Het specificeert geen implementatie.

Acceptatiecriteria zetten intentie echter om in duidelijke, testbare voorwaarden die bepalen of de story voltooid is. Ze zorgen dat je team afgestemd is op de scope, elimineren onduidelijkheid en bieden een meetbare standaard voor QA en belanghebbenden. Dit kan bijvoorbeeld het volgende bevatten:

• De zoekfunctie levert resultaten op die exact overeenkomen met de ingevoerde productnaam.

• De zoekfunctie levert resultaten op die gedeeltelijk overeenkomen met de ingevoerde productnaam.

• Resultaten worden weergegeven in een duidelijke, georganiseerde en gebruiksvriendelijke indeling.

Samen zorgen ze ervoor dat je team het goede product bouwt—en het goed bouwt.

Kenmerken van goede acceptatiecriteria

Acceptatiecriteria van hoge kwaliteit delen verschillende belangrijke kenmerken die ervoor zorgen dat ze gemakkelijk te begrijpen en te valideren zijn, en die de oplevering effectief sturen. Enkele veelvoorkomende kenmerken zijn:

Duidelijkheid en beknoptheid

Zeg precies wat je bedoelt, en zeg het simpel. Schrijf acceptatiecriteria in duidelijke, ondubbelzinnige taal die alle belanghebbenden—engineering, QA, design en product—op dezelfde manier kunnen interpreteren.

Houd ze kort en gericht op resultaten. Vermijd jargon en formuleringen die ruimte laten voor interpretatie.

Testbaarheid

Elk criterium moet objectief verifieerbaar zijn. Elk criterium moet duidelijk gekoppeld zijn aan een of meer uitvoerbare tests die objectief bevestigen of aan de vereiste is voldaan.

Testbaarheid elimineert alle subjectiviteit en zorgt ervoor dat iedereen eerlijk is over wat 'voltooid' werkelijk betekent.

Resultaat

Beschrijf het resultaat, niet het recept. Sterke criteria leggen uit wat de gebruiker zou moeten ervaren, niet de technische stappen die nodig zijn om het te bouwen.

Dit geeft engineers ruimte om problemen op te lossen en zorgt er tegelijkertijd voor dat het uiteindelijke gedrag aansluit bij de verwachtingen van gebruikers.

Meetbaarheid

Kwantificeer verwachtingen waar mogelijk om definitief te kunnen bepalen of een test geslaagd of mislukt is. Dit is waar precisie het testen versnelt en herzieningen vermindert.

Vervang vage uitspraken zoals: "De resultatenpagina moet er goed uitzien. Gebruik in plaats daarvan meetbare uitspraken zoals: "Elke productafbeelding wordt weergegeven met een minimumresolutie van 300×300 pixels."

Onafhankelijk

Elk criterium moet onafhankelijk zijn. Onafhankelijke criteria vereenvoudigen het testen, verminderen verbinding en maken het eenvoudiger om issues te diagnosticeren wanneer iets mislukt.

Als criteria van elkaar afhankelijk zijn om logisch te zijn, moet je ze waarschijnlijk herschrijven.

Waarom heb je acceptatiecriteria nodig?

Acceptatiecriteria zijn een van de krachtigste tools die je hebt om duidelijkheid te stimuleren, verloop te verminderen en ervoor te zorgen dat je daadwerkelijk hetgeen oplevert waarvan je dacht dat je het aan het genereren was. Daarom verdienen ze een permanente plek in je proces:

• Afstemming en gedeeld begrip: Wanneer je uitlegt hoe succes eruitziet, zitten alle betrokkenen, van engineering tot QA tot belanghebbenden op één lijn, zonder aannames die tot verrassingen leiden. Acceptatiecriteria dienen als het gedeelde contract voor wat je genereert en waarom.

• Minder dubbelzinnigheid en herzieningen: Een duidelijke definitie van gereed (DoD) is het snelste traject om herziening te voorkomen. Vage verwachtingen leiden tot eindeloze iteraties; expliciete criteria voorkomen dat subjectiviteit (en scope-creep) optreden. Duidelijkheid vooraf is altijd goedkoper dan correctie achteraf.

• Verbeterde testefficiëntie: Goed gedefinieerde acceptatiecriteria geven QA in feite een testblauwdruk. Ze vertalen direct naar verifieerbare stappen, waardoor het eenvoudig is om te bevestigen of de functie voldoet aan de verwachtingen of om gemakkelijk te zien waar dat niet het geval is.

• Verbeterd projectbeheer: Voor projectmanagers zijn acceptatiecriteria goud waard. Ze verdelen een functie in meetbare controlepunten, waardoor voortgang zichtbaar wordt en risico's worden verminderd. Elk afgevinkt criterium is een tastbare stap richting oplevering.

• Verhoogde tevredenheid van belanghebbenden: Wanneer functies consequent voldoen aan de verwachtingen, vertrouwen belanghebbenden het proces en het product. Bij duidelijke acceptatiecriteria stel je realistische verwachtingen en minimaliseer je onduidelijkheid. Daarnaast helpen ze bij het leveren van resultaten die echt voldoen aan gebruikersbehoeften.

Acceptatiecriteria overbruggen de kloof tussen visie en uitvoering. Ze zetten intentie om in afstemming, afstemming in actie, en actie in betrouwbare levering.

Als je wilt dat je teams snel bewegen en het juiste genereren, zijn acceptatiecriteria niet onderhandelbaar.

Zo stel je acceptatiecriteria op

Het opstellen van goed gedefinieerde acceptatiecriteria is van essentieel belang voor succesvolle softwareontwikkeling. Hier zijn enkele belangrijke stappen en tips voor begeleiding:

1. Begin met de userstory

Verwijs naar de userstory die verband houdt met de acceptatiecriteria. Dit zorgt ervoor dat de criteria aansluiten bij de gewenste functionaliteit.

2. Bepaal de resultaten

Benadruk de criteria voor de gebruikerservaring en de verwachte resultaten. Op welke manier is de functie nuttig voor de gebruiker? Voorkom dat je te veel ingaat op technische implementatiegegevens.

3. Stel de algehele testbaarheid vast

Zorg ervoor dat elk criterium kan worden omgezet in een duidelijke en verifieerbare test. Hierdoor kan de vraag of de functie voldoet aan de vereisten objectief worden geëvalueerd.

4. Bepaal de meetbaarheid

Druk de criteria waar mogelijk in meetbare termen uit. Dit maakt het mogelijk om tijdens het testen duidelijk te bepalen of de test is geslaagd of is mislukt.

5. Focus op onafhankelijkheid

Gebruik onafhankelijke criteria die je afzonderlijk kunt testen. Dit vereenvoudigt het testproces en voorkomt afhankelijkheden.

Overweeg om criteria voor tests voor gebruikersacceptatie (UAT) op te nemen naast de criteria van het ontwikkelingsteam. De UAT-criteria zijn erop gericht om ervoor te zorgen dat de functie voldoet aan de verwachtingen op het gebied van bruikbaarheid.

6. Bevorder samenwerking

Bevorder de samenwerking tijdens het creatieproces. Betrek de producteigenaar, softwareontwikkelaar (of teams) en andere relevante belanghebbenden bij het proces om te zorgen voor een uitgebreide set criteria die alle perspectieven weerspiegelt.

7. Herziening en verfijning

Aarzel niet om de acceptatiecriteria tijdens de ontwikkeling te herzien en te verfijnen. Naarmate het inzicht zich ontwikkelt, kun je overwegen om de criteria aan te passen aan de meest recente informatie.

8. Zorg voor duidelijkheid en beknoptheid

Gebruik duidelijke en beknopte taal die iedereen begrijpt. Technisch jargon of dubbelzinnige bewoordingen kunnen tot verwarring leiden.

Wie moet acceptatiecriteria opstellen?

Het schrijven van acceptatiecriteria in Agile workflows en methodologieomgevingen is een gezamenlijke inspanning en geen individuele. Hier is een overzicht van de typische functies:

• Producteigenaar: Heeft een diepgaand inzicht in de behoeften van de klant en de productvisie en speelt een cruciale rol bij het op gang brengen van de discussie en het beschrijven van de gewenste functionaliteit.

• Ontwikkelingsteam: Gebruikt hun technische expertise om waardevolle inzichten te bieden in de haalbaarheid en testbaarheid van de criteria en om geschikte manieren voor te stellen om de criteria vast te stellen voor een duidelijke evaluatie.

• Scrummaster (indien van toepassing): Een facilitator die de teamdiscussie begeleidt, ervoor zorgt dat iedereen zijn of haar mening kan geven en die ervoor kan zorgen dat de criteria voldoen aan de best practices.

De producteigenaar mag dan wel het proces initiëren, maar het laatste criterium moet een collectieve inspanning vormen die alle perspectieven van belanghebbenden integreert.

Deze gezamenlijke aanpak bevordert een gedeeld inzicht en vergroot de kans op een succesvol product.

Voorbeelden van acceptatiecriteria

Hieronder staan verfijnde voorbeelden van goed geschreven acceptatiecriteria. Elk van deze verbindt duidelijk een userstory met specifieke, meetbare voorwaarden die definiëren hoe 'gereed' eruitziet.

Voorbeeld 1: Product zoeken

• Userstory: Als klant wil ik producten op naam kunnen zoeken, zodat ik snel de items kan vinden die ik zoek.

• Acceptatiecriteria:

  • Het systeem levert alle producten op die exact overeenkomen met de ingevoerde zoekterm.

  • Het systeem levert gedeeltelijke overeenkomsten op wanneer de gebruiker ten minste drie tekens invoert.

  • Zoekresultaten tonen de productnaam, afbeelding en prijs in een duidelijke en georganiseerde lay-out.

  • De pagina met zoekresultaten ondersteunt paginering, met een maximum van 20 items per pagina.

  • Als er geen resultaten worden gevonden, toont het systeem een bericht 'Geen resultaten gevonden' met nuttige vervolgstappen.

Voorbeeld 2: Accountgegevens bewerken

• Userstory: Als geregistreerde gebruiker wil ik mijn accountgegevens bewerken zodat ik mijn profiel actueel kan houden.

• Acceptatiecriteria:

  • Gebruikers hebben toegang tot de sectie Profiel bewerken in hun accountinstellingen.

  • Gebruikers kunnen hun voornaam, achternaam, e-mailadres en telefoonnummer bijwerken.

  • Het systeem valideert verplichte velden en toont fouten voor ongeldige of ontbrekende gegevens.

  • Door op Opslaan te klikken worden de gegevens van de gebruiker bijgewerkt in het systeem.

  • Zodra de gegevens zijn bijgewerkt toont het systeem een bevestigingsbericht.

  • Als het bijwerken mislukt, toont het systeem een concrete foutmelding.

Voorbeeld 3: Rapportage van gebruikersactiviteit

• Userstory: Als beheerder wil ik activiteitenrapporten genereren om gebruikersactiviteit en betrokkenheid bij te houden.

• Acceptatiecriteria:

  • Het beheerdersdashboard bevat een speciale sectie met Rapporten.

  • Beheerders kunnen rapporten genereren over belangrijke gebruikersactiviteiten, waaronder aanmeldingen, productweergaven en aankopen.

  • Rapporten kunnen worden gefilterd op datumbereik en gebruikerstype.

  • Beheerders kunnen rapporten exporteren in ten minste twee indelingen, waaronder CSV en PDF.

  • Het systeem toont een duidelijke foutmelding als een rapport niet kan worden gegenereerd.

Deze voorbeelden laten zien hoe sterke acceptatiecriteria userstory's omzetten in uitvoerbare, testbare vereisten. Wanneer teams deze structuur volgen, leveren ze functies die consistent voldoen aan gebruikersverwachtingen en is er minder sprake van onduidelijkheid tijdens de ontwikkeling.

Schrijf duidelijke acceptatiecriteria met behulp van een gecentraliseerd platform

Wanneer iedereen vanuit een gecentraliseerde space werkt, is het veel eenvoudiger om acceptatiecriteria te ontwikkelen, bij te houden en te delen. Daarom gebruiken zoveel teams Jira om acceptatiecriteria te beheren.

Het is eenvoudig om ze direct in de story-omschrijving of het veld Acceptatiecriteria te plaatsen. En de opmaaktools van Jira, zoals opsommingslijsten en selectievakjes, helpen teams de voortgang bij te houden en vereisten duidelijk te houden.

Daarnaast kun je ontwerpen bijvoegen of linken naar Confluence-documentatie om ervoor te zorgen dat alle relevante context zeer toegankelijk is. Als je hulp nodig hebt bij het schrijven van consistentere en meer volledige acceptatiecriteria, identificeert Rovo, de AI-oplossing van Jira, hiaten en stelt het verbeteringen voor.

Samen zorgen al deze functies en tools voor minder onduidelijkheid en ondersteunen ze een soepeler ontwikkelingsproces. Ga vandaag nog aan de slag.

Acceptatiecriteria: Veelgestelde vragen

Wat is het verschil tussen acceptatiecriteria en de definitie van voltooid (DoD)?

Acceptatiecriteria en DoD zijn cruciaal voor het succes van projecten, maar ze dienen verschillende doelen. Acceptatiecriteria zijn gericht op de specifieke functionaliteiten waaraan een userstory moet voldoen om volledig te zijn voor de eindgebruiker.

DoD stelt een bredere reeks kwaliteitsnormen vast voor al het ontwikkelingswerk. Deze omvatten niet-functionele aspecten zoals de kwaliteit van de code en documentatie.

Acceptatiecriteria bepalen wat er moet gebeuren voor een userstory, terwijl DoD de algemene kwaliteitsnormen beschrijft voor de manier waarop een team ontwikkelingswerk voltooit.

Wanneer moet je acceptatiecriteria opstellen?

De ideale timing kan variëren, maar er zijn een paar belangrijke tijdvensters om rekening mee te houden. Eén optie is het identificeren van de eerste criteria tijdens sessies voor backlogverfijning, waarbij het team userstory's bespreekt en uitwerkt.

Een ander geschikt moment is tijdens de sprintplanning, wanneer het team samen de laatste hand legt aan de acceptatiecriteria voor userstory's die gepland staan voor de komende sprint. Dit zorgt ervoor dat de criteria actueel zijn en de meest recente inzichten weerspiegelen.

Definieer acceptatiecriteria voordat de ontwikkeling begint, om te zorgen voor duidelijke verwachtingen en een soepel ontwikkelingsproces.

Wat zijn enkele uitdagingen bij het schrijven van acceptatiecriteria?

Een veelvoorkomend probleem voor teams is dubbelzinnigheid in de criteria, wat kan leiden tot verkeerde interpretaties. Teams kunnen ook moeite hebben om een evenwicht te vinden tussen te specifieke en te vage criteria.

Meningsverschillen tussen belanghebbenden over wat 'voltooid' inhoudt kunnen het proces belemmeren. Het kan ook verleidelijk zijn om elk detail te behandelen, wat kan leiden tot omslachtige en uiteindelijk ineffectieve acceptatiecriteria.