Acceptatiecriteria zijn een belangrijk onderdeel van elke user story. Ze geven aan hoe je verifieert of de user story correct geïmplementeerd is. Acceptatiecriteria vertellen dus wat de software concreet moet doen.
In dit artikel lees je waar je rekening mee moet houden bij het opstellen van acceptatiecriteria. De kern van het artikel vind je in deze infographic.
Essentieel onderdeel van user stories
User stories zijn niet compleet zonder acceptatiecriteria. Al in 2001 schreef Ron Jeffries, de mede-bedenker van de user story techniek:
Een goede user story bestaat uit 3 onderdelen:
- Kort beschrijving
- Gesprekken tussen stakeholders en ontwikkelaars
- Acceptatiecriteria
Over acceptatiecriteria zei Ron Jeffries:
“At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they’ve done what is needed. She defines the acceptance tests that will be used to show that the story has been implemented correctly.”
Acceptatiecriteria vastleggen
Van een user story leg je in eerste instantie alleen een korte beschrijving vast, gewoonlijk “Als <type gebruiker> wil ik <functionaliteit>, zodat <businesswaarde>”.
Na verdere afstemming met stakeholders en ontwikkelaars worden daar acceptatiecriteria aan toegevoegd, zodat duidelijk is wat er van de software wordt verwacht.
Je maakt een user story verifieerbaar door er acceptatiecriteria aan toe te voegen.
De makkelijkste manier om acceptatiecriteria vast te leggen is met een eenvoudige en concrete zin die te verifiëren is.
Van oorsprong begonnen acceptatiecriteria met ‘Testen dat’ of ‘Testen met’. Daarmee maak je de verifieerbaar expliciet. Tegenwoordig blijft het impliciet omdat we ‘Testen dat’ of ‘Testen met’ meestal achterwege laten.
Een voorbeeld
Voor de user story:
Als boeker van een vliegreis wil ik mijn gekochte vliegticket online kunnen wijzigen, zodat ik niet hoef te bellen naar de klantenservice.
… zouden bijvoorbeeld onderstaande acceptatiecriteria kunnen gelden:
- Een vliegticket kan tot 4 uur voor de geplande vertrektijd gewijzigd worden
- Er wordt EUR 150,- wijzigingskosten in rekening gebracht
- Er wordt een bevestigingsmail naar de klant gestuurd
- De wijziging is real-time zichtbaar in het account van de klant
Andere veel gebruikte manieren om acceptatiecriteria vast te leggen zijn ‘How to demo’ en ‘Specification by example (Given-when-then)’.
Volledigheid acceptatiecriteria
Net als bij requirements is het ook bij acceptatiecriteria niet de bedoeling om ze volledig te beschrijven. Laat in elk geval voor de hand liggende acceptatiecriteria achterwege.
In agile gaat voortschrijdend inzicht en veelvuldig afstemming met stakeholders boven vasthouden aan eerder afgesproken requirements en bijbehorende acceptatiecriteria.
Verder is het weglaten of versoepelen van een acceptatiecriterium één van de manieren om een te grote user story op te delen in kleinere stories. Voor de versoepelde eis definieer je dan een nieuwe user story.
Een voorbeeld
In het voorbeeld hierboven zou je het 1e acceptatiecriterium achterwege kunnen laten en in plaats daarvan bijvoorbeeld één van onderstaande user stories toevoegen. Daarbij is afstemming met stakeholders en doorvragen naar de businesswaarde (gerelateerd aan het productdoel) noodzakelijk.
Als boeker van een vliegreis wil ik mijn gekochte vliegticket tot kort voor vertrek kunnen wijzigen, zodat ik onvoorziene omstandigheden kan opvangen.
Alternatief:
Als prijsbewuste boeker van een vliegreis wil ik mijn gekochte vliegticket kunnen wijzigen, zodat ik met weinig risico vroegtijdig kan boeken.
Ook voor het 2e acceptatiecriterium geven we een bijvoorbeeld
Als financieel verantwoordelijke wil ik dat er voor vluchtwijzigingen kosten in rekening gebracht worden, zodat daarmee de kosten gedekt worden. – Alternatief: … zodat we daarmee een extra inkomstenbron aanboren.
Als operationeel verantwoordelijke wil ik dat er voor vluchtwijzigingen kosten in rekening gebracht worden, zodat vluchtwijzigingen ontmoedigd worden.
Hoe je epics en user stories opdeelt in kleinere stories, leg ik haarfijn uit in de online training Juwelen van user stories. Hierin ontdek je hoe je met een simpele techniek een overzichtelijke backlog creëert met user stories die veel waarde leveren.
Extra tip
De meest gemaakte fout bij acceptatiecriteria en gedetailleerde requirements is dat er al oplossingen in plaats van eisen en wensen beschreven worden.
Blijf bij WAT het systeem moet doen en laat HOE het systeem het doet over aan de ontwikkelaars.
Maak jij duidelijk onderscheid tussen requirements en acceptatiecriteria? Hoe maken jullie de user stories verifieerbaar/meetbaar? We horen graag van je in een reactie hieronder.
Nicole de Swart & Priya Soekhai
Nicole,
functionele acceptatiecriteria zijn kritisch voor de klant, de opdrachtgever. Zonder acceptatiecriteria voor gebruik, user experience zal het business voordeel deels achterwege blijven (het zijn mensen die het nader order zullen moeten doen). Dit wegzetten als afgedekt in de sprint review, de acceptatie van de gebruiker laten afhangen van wollige, algemene statements is niet enkel kort door de bocht maar mist de multidimensionaliteit van het geheel. Ten opzichte hiervan enkel statements die tot nadenken kunnen stemmen:
systemen leveren nooit waarde (jawel NOOIT), ze zijn niet meer dan enablers voor de business;
een systeem zonder de gepaste functionaliteit is waardeloos als enabler
een systeem dat niet op de juiste manier werkt en niet mensgericht is ontworpen heeft slechts beperkte waarde als enabler
een goed systeem doet wat het moet doen, doet niet wat het niet mag en doet dit op een menswaardige en respectvolle manier. Zet daarbij nog security, privacy, performantie… en het beeld wordt steeds rijker geschakeerd. Briljanten hebben niet genoeg aan een facet om te schitteren, met IT systemen is dat net zo
Wat mij opvalt is dat ik de in het voorbeeld genoemde acceptatiecriteria al als zelfstandige user story zou hebben opgenomen. Ik denk dat ik user stories veel verder detailleer, waardoor acceptatie criteria eigenlijk een op een uit de user story blijken. En kijkend naar het voorbeeld: ik denk niet dat een boeker van een vliegreis als requirement zal stellen dat hij 150 euro wijzigingskosten in rekening gebracht moet krijgen. Dat zou ik logischer vinden om als user story van de commercieel directeur op te nemen.
Van de genoemde acceptatiecriteria kun je inderdaad ook zelfstandige user stories maken, zoals we aan het eind van het artikel gedaan hebben. Het kan allebei en hangt onder andere af van de ontwikkelsnelheid van het team en de lengte van de sprints.
Jammer dat je het vierde criterium niet hebt aangepakt, het is een schoolvoorbeeld waarbij implementatie en oplossing keihard worden vastgelegd.
Het derde criterium is dubbel omdat het zowel richting boeker werkt – verzekeren dat wijziging gelukt is – en naar de maatschappij – vermijden oproepen klantenservice, minder personeel, goedkoper. Het is ook een UX criterium maar zwak omdat het triviale werking is (je moet toch ook niet bepalen in de acceptatiecriteria dat je je paswoord moet kunnen vragen bij inloggen als je het vergeten bent – dat is triviaal).
Rekening houdend met de opmerking van Fred, is er in dit voorbeeld geen enkel criterium dat echt deugt.
Daar bovenop is het voordeel in de user story moeilijk een voordeel te noemen, meer efficiëntie heeft meestal weinig waarde en net zoals het derde acceptatiecriterium is dat ook hier “tweeslachtig”. Het eerste alternatief vermeld bij het eerste criterium is heel wat beter, het tweede dan weer minder (positieve formulering levert een voordeel, een negatieve formulering – risico – is het vermijden van een nadeel).
Voordelen moeten voor de user-rol zijn, acceptatiecriteria moeten aan dit voordeel verbonden zijn en dus ook aan de user-rol, anders kan je die sterk in vraag stellen – lijkt mij.