samen
werken
Wat zijn acceptatiecriteria? (incl. do’s & don’ts)
Met acceptatiecriteria geef je detail aan een User Story zodat je weet wanneer een User Story klaar is. Acceptatiecriteria komen voort uit gesprekken tussen de Product Owner, stakeholders en de Developers wanneer je volgens het Scrum Framework werkt. In dit artikel leer je hoe User Stories en acceptatiecriteria elkaar kunnen helpen, wat de voordelen zijn en wat je wel en niet moet doen bij het schrijven van acceptatiecriteria.
User Stories en acceptatiecriteria hebben elkaar nodig
Neem de volgende User Story:
“Als huiseigenaar met een grote tuin wil ik mijn gazon op een snelle en makkelijke manier kunnen maaien zodat ik daar weinig tijd mee kwijt ben.”
Welke oplossing komt als eerste in je hoofd op? Wellicht een grasmaaier die je in het stopcontact moet doen? Een robotgrasmaaier? Of zo’n ouderwetse grasmaaier waarbij je achteraf nog alle blaadjes bij elkaar moet vegen (uit eigen ervaring zou ik die laatste afraden).
Eén ding is zeker. Met deze User Story krijg je het idee dat er een grasmaaier moet komen, maar de invulling hoe de grasmaaier eruit moet zien staat nog open. Als een Product Owner deze User Story aan zijn Developers laat zien, dan is het mogelijk dat de ene Developer de User Story heel anders zal interpreteren dan de ander. Dat is fijn, want diverse perspectieven op een probleem verhogen de kans op de beste oplossing. Echter wil je wel dat de ideeën aan de eisen van de opdrachtgever voldoen. Daarom moeten we de User Story nog afbakenen. Hoe doen we dat? Met acceptatiecriteria!
Zie hier vijf bijbehorende acceptatiecriteria voor de bovenstaande User Story:
- Het product heeft een benzinemotor
- Het product heeft 4 wielen
- Elk wiel heeft een rubberband
- Het product heeft een stuur
- Het product heeft een stalen carrosserie
Zoals je gelijk kunt zien waren de drie interpretaties van onze mogelijke grasmaaier allemaal verkeerd. De tuin is namelijk erg groot en de huiseigenaar is niet begaan met technologie en vindt alles wat digitaal is maar niks. Kortom een zitmaaier met een benzinemotor moet de klus klaren.
Wat zijn de voordelen van acceptatiecriteria?
De voordelen zijn: accceptatiecriteria definiëren de kaders waar de User Story aan moet voldoen, acceptatiecriteria helpen het team om een gezamenlijk begrip te vormen van de User Story en acceptatiecriteria maken het gemakkelijk om te testen.
1. Acceptatiecriteria definiëren de kaders waar de User Story aan moet voldoen
Acceptatiecriteria geven de Developers kaders en richtlijnen hoe complex de oplossing voor het probleem mag zijn. Doe je dit niet en je hebt een paar enthousiaste Developers in je team, dan kan het zomaar zijn dat ze een robotgrasmaaierdrone maken die over het gras vliegt en met lasers het gazon tot op de milimeter nauwkeurig bijwerkt. Leuke gadget, maar voor de meeste eindgebruikers onbetaalbaar.
2. Acceptatiecriteria helpen het team om een gezamenlijk begrip te vormen van de User Story
Doordat er tijdens Product Backlog Refinement of de Sprint Planning de User Stories inclusief acceptatiecriteria worden besproken zullen de Developers vragen stellen aan de Product Owner over de acceptatiecriteria. Dit geeft een diepere laag aan het gesprek waardoor belangrijke details niet vergeten worden, die anders tijdens de sprint voor problemen kunnen zorgen.
3. Acceptatiecriteria maken het gemakkelijk om te testen
Elke User Story is pas ‘sprintklaar’ als die voldoet aan de Definition of Ready. Door het toevoegen van acceptatiecriteria kun je heel eenvoudig testen wanneer een User Story klaar is. Alleen wanneer aan alle acceptatiecriteria volledig is voldaan, kun je een User story opleveren. Let er wel op dat de User Story pas deel wordt van het increment als die voldoet aan de Definition of Done. Wat precies het verschil is tussen de acceptatiecriteria en de Definition of Done kun je in het artikel van de Definition of Done lezen.
Hoe schrijf je acceptatiecriteria: do’s & don’ts?
Soms kan het best lastig zijn om goede acceptatiecriteria te bedenken. Mocht je hiermee problemen hebben dan kun je jezelf altijd het volgende afvragen: ‘Hoe weten we wanneer we klaar zijn?’. Door jezelf deze vraag te stellen kun je makkelijker acceptatiecriteria identificeren. Dan rest ons alleen nog de vraag hoe je ze schrijft.
Het schrijven van goede acceptatiecriteria is een kunst die je pas echt gaat beheersen door het veel te doen. Maar wat als je het altijd op de verkeerde manier doet? Dan doe je het na een jaar nog steeds verkeerd. Daarom geef ik je hier een aantal richtlijnen die je gaan helpen om acceptatiecriteria te schrijven waar menig Agile Coach nog wat van kan leren. De beste acceptatiecriteria voldoen aan het volgende:
Blijf bij de “wat” en vermijd de “hoe”
Misschien nog wel het lastigste van acceptatiecriteria is dat je de balans moet vinden tussen te gedetailleerd, precies goed en te onduidelijk. Dat is ook gelijk de #1 fout die sommige Product Owners maken. Wij zien te vaak dat de Product Owner te veel detail toevoegt waardoor de Developers helemaal geen ruimte hebben om hun creativiteit naar boven te brengen. Om een voorbeeld te geven:
User Story: “Als gamer wil ik digitaal mijn emotie kunnen uitdrukken, zodat andere gamers kunnen zien hoe gelukkig ik vandaag ben”
Acceptatiecriteria die bij deze user story kunnen horen:
Te gedetailleerd: de gebruiker kan een computerkarakter kiezen door op een afbeelding te klikken van het hoofd van het computerkarakter.
Precies goed: de gebruiker kan een computerkarakter kiezen.
Te onduidelijk: de gebruiker heeft een computerkarakter.
Er zijn geen harde regels die ik je hiervoor kan meegeven aangezien elk project en elk Scrum Team verschillend is. De richtlijn is dat je de acceptatiecriteria zo wil formuleren dat het niet de oplossing definieert waardoor de creativiteit van de Developers wordt afgenomen om wellicht een betere oplossing te bedenken waaraan de Product Owner in eerste instantie niet had gedacht.
Hoeveel acceptatiecriteria per User Story?
Elk acceptatiecriterium staat op zichzelf. Mocht dit niet het geval zijn dan wil je de acceptatiecriteria opsplitsen. Als vuistregel kun je aanhouden dat een User Story tussen de vier en acht acceptatiecriteria heeft. Met minder dan vier heeft de User Story waarschijnlijk te weinig detail en met meer dan acht kan de User Story waarschijnlijk beter gesplitst worden in twee kleinere User Stories.
Vermijd subjectief en dubbelzinnig taalgebruik
“De marketingcampagne verloopt vlotter, beter, juister.” Waarschijnlijk roept de vorige zin veel vragen bij je op. Je bent niet de enige. Probeer acceptatiecriteria zo specifiek en SMART mogelijk te benaderen. Zoals eerder genoemd helpen acceptatiecriteria je om te testen en daarom moeten ze meetbaar zijn. In andere woorden: ze moeten zo helder geformuleerd worden dat ze niet voor verschillende interpretaties vatbaar zijn, maar niet zo gedetailleerd dat ze de oplossing beschrijven. Klinkt wellicht wat complex, maar ik heb nooit gezegd dat het makkelijk was.
Ook interessant:
- Teaminterventies, hoe pak ik dat aan? (+werkvorm)
- Waarom is transparantie in Scrum zo belangrijk?
- Harvard methode als hulpmiddel bij stakeholdermanagement
- 3 Scrum mythes: zijn ze waar of onwaar?
Wil je meer weten over acceptatiecriteria en hulp krijgen van een van onze Agile Coaches? Of wil je over het algemeen meer leren over de Product Owner rol? Schrijf je dan in voor de Product Owner Training. Of neem contact op met een van onze consultants via info@agilescrumgroup.nl of 020 2614 195.
