5.2 User stories en acceptatiecriteria
gegeven–als–dan, drie C’s, epic
Eerst de basis
Een eis opschrijven vanuit de gebruiker
Een user story beschrijft een wens vanuit het perspectief van degene die er iets aan
heeft. De vaste vorm:
Het derde deel, de zodat-clausule, is het belangrijkste en wordt het vaakst
overgeslagen. Daar staat waaróm het de moeite waard is — en dus waarop het team mag afwijken van
de letterlijke wens als er een betere oplossing is.
Een story is bewust kort. Hij is geen specificatie maar een belofte tot een gesprek: de
drie C’s — Card (het kaartje), Conversation (het gesprek erover) en
Confirmation (hoe u vaststelt dat het klopt).
Van story naar acceptatiecriteria
Acceptatiecriteria maken concreet wanneer déze story doet wat hij belooft. Vaak
geschreven in de gegeven–als–dan-vorm (given–when–then).
Story: Als webshopklant wil ik mijn bestelling kunnen volgen, zodat
ik weet wanneer ik thuis moet zijn.
Acceptatiecriteria
- Gegeven een verzonden bestelling, als ik mijn ordernummer invoer, dan zie
ik de actuele status en de verwachte bezorgdag. - Gegeven een onbekend ordernummer, als ik het invoer, dan krijg ik een
begrijpelijke melding en geen technische foutcode. - Gegeven een bezorgde bestelling, als ik de status opvraag, dan zie ik het
tijdstip van bezorging.
beschrijven gedrag. De Definition of Done geldt voor alle items en beschrijft
kwaliteit (getest, gereviewd, gedocumenteerd). Een item is pas af als het aan beide
voldoet.
epic. Die splitst u tijdens refinement op — zie 5.3.