Acceptatiecriteria schrijven in Jira — met praktische voorbeelden

“Klanten kunnen hun notificatievoorkeuren wijzigen” klinkt als een duidelijk Jira-issue totdat iemand het gaat bouwen. Wordt een wijziging direct opgeslagen? Wat gebeurt er als opslaan mislukt? Staat de voorkeur er morgen nog? Welke e-mails worden beïnvloed?

Acceptatiecriteria maken van die open vragen afgesproken, waarneembare resultaten. Ze helpen de mensen die een wijziging aanvragen, bouwen en beoordelen vanuit dezelfde verwachtingen te werken.

In deze handleiding ontwikkelen we criteria voor een fictieve klantenportaalfunctie, verbeteren we vage eisen en voegen we een praktische checklist toe aan Definition of Done & AC van Power Pack. Je hebt geen speciaal schrijfformaat nodig om te beginnen. Duidelijke voorwaarden en resultaten zijn genoeg.

Wat zijn acceptatiecriteria?

Acceptatiecriteria beschrijven de voorwaarden waaraan een bepaald stuk werk moet voldoen om te worden geaccepteerd. Ze richten zich op het verwachte resultaat van dat item. Atlassian onderscheidt ze van de Definition of Done, die de bredere kwaliteitsnorm voor voltooid werk beschrijft. Zie de handleiding over acceptatiecriteria van Atlassian.

In ons voorbeeld is “Een opgeslagen notificatiekeuze blijft geselecteerd nadat de klant opnieuw inlogt” een acceptatiecriterium. “De implementatie is beoordeeld” hoort bij de gedeelde Definition of Done.

Dat onderscheid houdt beide lijsten nuttig. De acceptatiecriteria leggen uit of deze functie doet wat het team heeft afgesproken. De Definition of Done legt uit of het werk aan de bredere voltooiingsnorm van het team voldoet.

Geen van beide lijsten hoeft elke implementatiestap te bevatten. “Een databaseveld maken” kan een noodzakelijke technische taak zijn, maar vertelt een klant of beoordelaar niet of de voorkeur zich correct gedraagt.

Begin met één klantresultaat

Ons fictieve issue heet “Laat klanten de wekelijkse samenvattingsmail beheren”. Het beoogde resultaat is dat een ingelogde klant kan kiezen of die een wekelijkse samenvatting ontvangt, zonder essentiële accountberichten te veranderen.

Voordat het team criteria schrijft, spreekt het enkele scopebesluiten af. De instelling heeft een expliciete knop Save. De klant wijzigt alleen de eigen voorkeur. De voorkeur geldt voor samenvattingen die nog niet in de wachtrij staan. Berichten die al in de wachtrij staan, vallen buiten de bezorgregel van dit issue.

Deze details zijn voor het voorbeeld bedacht. Je team moet het eigen werkelijke gedrag bepalen in plaats van ze als producteisen over te nemen.

Een korte scopenotitie kan voorkomen dat een lange checklist alle context moet dragen. In de Jira-beschrijving legt het team vast dat dit issue één voorkeur op de accountinstellingenpagina betreft. Bezorgdagen kiezen, e-mailadressen wijzigen en voorkeuren van andere klanten beheren zijn afzonderlijk werk.

Nu kunnen de criteria zich richten op de resultaten die aantonen of deze specifieke wijziging werkt.

Schrijf eerst het normale pad

Begin met de ervaring die je voor de meeste klanten verwacht. Beschrijf de beginsituatie, de actie en het waarneembare resultaat in gewone taal.

Bijvoorbeeld: “Wanneer een ingelogde klant wekelijkse samenvattingen uitzet en succesvol opslaat, toont het opnieuw openen van accountinstellingen dat wekelijkse samenvattingen uitstaan.” Een beoordelaar kan de beginsituatie maken, de actie uitvoeren en het resultaat inspecteren.

Die zin is nuttiger dan “Voorkeuren worden correct opgeslagen”. Hij benoemt welke voorkeur verandert, wanneer de wijziging ingaat en hoe iemand die kan controleren.

Het team heeft ook de omgekeerde richting nodig. Een bediening die samenvattingen wel uitzet maar niet kan aanzetten, is onvolledig. Schrijf een afzonderlijk criterium wanneer het omgekeerde gedrag een eigen controle verdient.

Forceer ongerelateerde resultaten niet in één regel. Opslaan, toetsenbordbediening, e-mailbezorging en foutafhandeling kunnen allemaal belangrijk zijn, maar één enorm criterium maakt het lastig te tonen welk deel nog aandacht nodig heeft.

Voeg foutgevallen en grensgevallen toe

Het normale pad veronderstelt dat opslaan lukt. Vraag wat de klant moet zien als die aanname niet klopt.

Ons team kiest deze regel: als het opslagverzoek mislukt, toont de pagina een fout en geen succesbevestiging. Bij het opnieuw openen blijft de eerder opgeslagen voorkeur staan. Dat geeft de beoordelaar een concreet foutgeval om in de testomgeving van het team uit te proberen.

Bekijk daarna de grens van de functie. De instelling voor wekelijkse samenvattingen mag een e-mail voor wachtwoordherstel niet tegenhouden. De keuze van de klant moet ook een nieuwe inlogsessie overleven. Dit zijn verschillende aandachtspunten, dus krijgen ze afzonderlijke criteria.

Schrijf niet “Alle randgevallen afgehandeld”. Benoem de gevallen die belangrijk zijn. Een nuttig gesprek begint vaak met drie vragen: wat kan misgaan, wat moet ongewijzigd blijven en wat gebeurt er later?

Als het team geen verwacht resultaat kan afspreken, leg het openstaande besluit dan vast voordat de implementatie te ver gevorderd is. Een onbeantwoorde vraag wordt geen bruikbaar criterium doordat die in een checklist staat.

Een uitgewerkte checklist met acceptatiecriteria

Dit is de eerste volledige versie voor het fictieve issue. Elke regel beschrijft een resultaat dat het team afzonderlijk kan controleren.

• Het openen van accountinstellingen toont de huidige opgeslagen voorkeur voor wekelijkse samenvattingen van de klant.
• Na het uitzetten van wekelijkse samenvattingen en succesvol opslaan, toont het opnieuw openen van accountinstellingen dat de voorkeur uitstaat.
• Na het aanzetten van wekelijkse samenvattingen en succesvol opslaan, toont het opnieuw openen van accountinstellingen dat de voorkeur aanstaat.
• Na succesvol opslaan blijft de opgeslagen voorkeur behouden bij uitloggen en opnieuw inloggen.
• Als opslaan mislukt, verschijnt een fout, verschijnt geen succesbevestiging en toont het opnieuw openen van instellingen de eerder opgeslagen voorkeur.
• Een klant bij wie de voorkeur uitstaat ontvangt geen wekelijkse samenvatting die na het succesvol opslaan nieuw in de wachtrij is gezet.
• Een klant bij wie de voorkeur aanstaat blijft volgens de bestaande planningsregels in aanmerking komen voor de volgende wekelijkse samenvatting.
• Wekelijkse samenvattingen uitzetten voorkomt niet dat de klant een aangevraagde e-mail voor wachtwoordherstel ontvangt.

De bezorgregels hangen af van het scopebesluit over berichten in de wachtrij. Het team legt die context bij het issue vast, zodat de beoordelaar niet aanneemt dat de instelling e-mails terughaalt die al worden verzonden.

Deze criteria hebben ook een werkbare controleaanpak nodig. Voor het bezorggedrag bepaalt het team hoe het in de testomgeving een samenvatting kan activeren of waarnemen. Een criterium kan duidelijk zijn geschreven en toch moeilijk te controleren zijn als niemand toegang heeft tot het benodigde account of bezorgbewijs.

Verbeter vage criteria voordat je ze toevoegt

Een korte tekstcontrole voorkomt vaak langere meningsverschillen later. Lees elke regel en vraag of twee mensen succes verschillend kunnen interpreteren.

Het laatste voorbeeld bewijst op zichzelf geen gebruiksvriendelijkheid. Het vervangt één vage zin door één nuttige, beperkte controle. Bredere gebruiksvriendelijkheidsdoelen kunnen onderzoek of meerdere afgesproken observaties nodig hebben.

Wees ook voorzichtig met verzonnen precisie. Een responstijdeis van twee seconden klinkt meetbaar, maar schept een echte verplichting. Spreek de omstandigheden en reden voor een prestatiedrempel af voordat je die opneemt.

Zet de criteria in Power Pack

Open het Jira-issue en zoek de kaart Definition of Done & AC. Selecteer het tabblad Acceptance Criteria. De lijst staat los van het tabblad Definition of Done, dus controleer het geselecteerde tabblad voordat je inhoud invoert.

Voer voor één criterium de titel in en selecteer Add of druk op Enter. Gebruik beknopte titels die het verwachte resultaat behouden. Als een criterium veel context nodig heeft, bewaar die context in de Jira-beschrijving of gekoppelde teamdocumentatie.

Selecteer voor meerdere regels Bulk Import en plak een Markdown-opsomming. Je kunt de voorbeeldregels hierboven kopiëren met een streepje en een spatie vóór elke regel. Markdown-lijsten met selectievakjes worden ook ondersteund.

Controleer de resulterende regels na het importeren. De actie voegt toe aan de huidige lijst, dus dezelfde checklist opnieuw importeren kan bestaande regels dupliceren. Aangevinkte Markdown-selectievakjes worden als voltooid toegevoegd; begin met niet-aangevinkte regels tenzij de resultaten van het huidige issue werkelijk zijn gecontroleerd.

Als een regel onjuist is, bespreek de vervangende tekst met het team, voeg de juiste regel toe en verwijder de verouderde via de bevestigingsvraag. Houd de ondersteunende discussie in het issue duidelijk wanneer een wijziging de afgesproken reikwijdte beïnvloedt.

Beoordeel resultaten voordat je ze afvinkt

Vraag vóór de implementatie iemand die bij de controle betrokken is om de voorgestelde criteria door te lopen. Die kan ontbrekende beginvoorwaarden ontdekken of een resultaat dat met de beschikbare testopstelling niet waarneembaar is.

Controleer na de implementatie elk resultaat en leg bewijs vast via het normale Jira- of documentatieproces van het team. Selecteer de knop Done van een regel wanneer het afgesproken resultaat geslaagd is. Opnieuw selecteren zet die terug naar open als een latere bevinding de controle heropent.

Een voorkeur kan bijvoorbeeld een paginavernieuwing overleven maar na opnieuw inloggen worden teruggezet. Het criterium voor het opnieuw openen van de pagina kan slagen terwijl het criterium voor behoud tussen sessies onvoltooid blijft. Afzonderlijke regels bewaren dat nuttige onderscheid.

Power Pack volgt de voortgang van de checklist; het voert de tests niet uit en bepaalt niet automatisch wie ze heeft beoordeeld. Als de beoordeling controle door een genoemde persoon of een gedateerd resultaat vereist, leg die details dan expliciet vast in je normale proces.

Gebruik beide aantallen zonder ze voor bewijs aan te zien

Acceptance Criteria en Definition of Done tonen elk hun eigen aantallen voltooide en totale regels. De gereedheidsindicator toont alleen Ready for Release als beide lijsten niet leeg zijn en elke regel in beide voltooid is. Anders staat er In Verification.

Dat is een samenvatting van de ingevoerde checkliststatus. Die kan niet aantonen dat de criteria elk belangrijk gedrag afdekken of dat het ondersteunende bewijs deugt. Die dwingt ook geen Jira-workflowovergangen af en blokkeert geen merges.

Ons notificatie-issue kan alle acht acceptatiecriteria voltooid hebben terwijl ondersteuningsinformatie in Definition of Done nog openstaat. De functieresultaten zijn geslaagd, maar de bredere voltooiingsafspraak van het team heeft nog een open regel.

Begin met één aankomend Jira-issue. Schrijf het klantresultaat op, spreek de belangrijke voorwaarden en resultaten af en voeg de criteria in Power Pack toe naast de gedeelde Definition of Done. Bekijk de lijst met de mensen die de wijziging gaan bouwen en controleren. De opbrengst is minder aannames achter een zin die aanvankelijk vanzelfsprekend klonk.

• Atlassian — Wat zijn acceptatiecriteria?