Hoeveel informatie moet ik vastleggen bij een user story?” Dit is denk ik de vraag die me het meeste wordt gesteld. Daar achteraan volgen dan meestal de vragen “En welke info neem ik in de acceptatiecriteria op? Kun je een voorbeeld van user stories met acceptatiecriteria geven?”
Het zijn lastige vragen omdat er geen eenduidig antwoord op te geven is. De benodigde mate van detail is namelijk afhankelijk van de situatie. Net als zo veel dingen in agile 🙂. Hoever je user stories en acceptatiecriteria moet uitwerken, is onder andere afhankelijk van de volwassenheid van het agile team en van de afstemming met de business.
Ik snap dat agile richtlijnen als …
“Just in time en just enough requirements zodat er op ieder moment in het project precies genoeg requirements zijn uitgewerkt om het software ontwikkelproces soepel te laten verlopen.”
… niet genoeg houvast geven. Dus heb ik een voorbeeld user stories met acceptatiecriteria uitgewerkt.
Voorbeeld uitgewerkt
Eerlijk gezegd was ik huiverig voor het uitwerken van een voorbeeld. Een voorbeeld roept vaak meer vragen op dan het beantwoordt. Maar ik begrijp de behoefte en ben na aanhoudende verzoeken overstag gegaan.
Ik heb geprobeerd just enough context te geven om het voorbeeld over te brengen. Beheerdocumentatie heb ik niet meegenomen in dit voorbeeld.
Context
Een opleidingsinstituut gespecialiseerd in in-house trainingen is een competentie portal aan het ontwikkelen. Het portal biedt toetsen om uiteenlopende competenties van medewerkers te kwantificeren. Hiermee kunnen HR-managers kennishiaten van medewerkers en sollicitanten opsporen.
Het portal krijgt een databank met duizenden vragen. Het opleidingsinstituut gaat het competentie portal gratis beschikbaar stellen aan haar grote klanten.
Epics
De voornaamste epics gaan over het toevoegen van nieuwe toetsen en toetsvragen en het afnemen van toetsen. Voor het afnemen van toetsen heeft het opleidingsinstituut de volgende epic onderkend:
Als HR-manager wil ik (potentiële) medewerkers aan een toets onderwerpen, zodat ik kennishiaten kan identificeren en ons opleidingsaanbod daarop aanpassen.
De product owner en de teamleden hebben deze epic tijdens een product backlog refinement besproken. Ze hebben de epic opgesplitst in kleinere user stories en (er in latere refinements) acceptatiecriteria aan toegevoegd. Ook hebben ze schermschetsen en foto’s van het whiteboard gemaakt.
Let op dat hoe minder volwassen het agile team (inclusief product owner) is, hoe meer informatie er gedocumenteerd moet worden. Dat kan bijvoorbeeld door extra uitleg en/of acceptatiecriteria toe te voegen.
Verder moeten sprint ready user stories zo klein zijn dat ze in 1 of 2 dagen (max. halve sprint) geïmplementeerd kunnen worden. Dat is dus voor elk team en elke technische omgeving anders.
Voorbeelden van user stories met acceptatiecriteria erbij
Hieronder vind je 5 user stories met bijbehorende acceptatiecriteria als voorbeeld.
User story 1. Toets samenstellen
Als opleidingsmanager wil ik een nieuwe toets samenstellen, zodat ik deze aan (potentiële) medewerkers kan voorleggen.
- Testen dat hij het aantal vragen per onderwerp en het totaal aantal vragen kan instellen.
- Testen dat hij de vragen zelf kan selecteren uit de databank of dat hij het systeem dat random kan laten doen.
N.B. Stel het opleidingsinstituut wil uitproberen of het idee van een competentie portal aanslaat. Na deze user story zouden ze het portal alvast beschikbaar stellen aan (een beperkt aantal) klanten. Het moet dan ook mogelijk zijn om de toetsen te printen, zodat ze handmatig ingevuld en nagekeken kunnen worden.
User story 2. Uitslag van de toets zien
Als opleidingsmanager wil ik de uitslag van de toets zien, zodat ik voor passende opleidingen kan zorgen.
- Testen dat hij de resultaten per vraag en per medewerker kan zien.
- Testen dat uitsluitend de opleidingsmanager het resultaat kan zien.
User story 3. Verzoeken toets in te vullen
Als opleidingsmanager wil ik medewerkers verzoeken om een bepaalde toets te maken, zodat ik aan de hand van de resultaten de kennishiaten kan beoordelen.
- Testen dat de ingevoerde namen en e-mailadressen bewaard blijven voor latere toetsen.
- Testen dat hij ook externe e-mailadressen (bv. van sollicitanten) kan invoeren.
- Testen of hij de verzendlijst te zien krijgt.
- Testen dat de e-mail bevat 1) een link naar de toets en 2) een standaardtekst die hij kan aanpassen.
N.B. Ook voor acceptatiecriteria geldt dat je niet meer opschrijft dan nodig is. Bijvoorbeeld ‘Testen of het systeem alle medewerkers in de verzendlijst het verzoek stuurt’ is overbodig (tenzij je de acceptatiecriteria als een traditionele afvinklijst gebruikt).
User story 4. Medewerkersgroepen definiëren
Als opleidingsmanager wil ik een groep met medewerkers definiëren, zodat ik ze in een keer kan verzoeken om de toets te maken.
- Testen met groepen van 0, 1, 200 en 1.001 personen.
N.B. Neem in het acceptatiecriterium vooral minimum- en maximumwaarden en foutieve waarden op.
User story 5. Toetsen zoeken
Als opleidingsmanager wil ik zoeken in de bestaande toetsen, zodat ik kan bepalen of ik er één ga hergebruiken of een nieuwe samenstel.
- Testen dat hij kan zoeken op datum, naam en onderwerp van de toets.
Er zijn nog genoeg andere user stories bij deze epic te definiëren, maar ik denk dat het idee zo wel duidelijk is.
Haal meer uit user stories
Wil je niet alleen goede user stories en acceptatiecriteria schrijven maar ook de ander aspecten van de user story techniek ten volle benutten, dan raad ik je mijn e-book ‘Haal meer uit User Stories’ aan. Daarin lees je hoe je in minder tijd meer resultaat boekt door slim toepassen van user stories.
Heb je iets aan het uitgewerkte voorbeeld gehad? Ik stel het op prijs als je dat even laat weten in het reactieveld hieronder. Of vragen en opmerkingen zijn uiteraard ook welkom.
Nicole de Swart
Dank Nicole voor uitgewerkte voorbeeld.
Je schrijft het volgende:
“Let erop dat hoe minder volwassen het agile team (inclusief product owner) is, hoe meer informatie er gedocumenteerd moet worden. Dat kan door acceptatiecriteria of extra uitleg toe te voegen.”
Hoe voorkom je dan ‘getouwtrek’ over het ‘hoe’? Dus dat wel aan het acceptatiecriterium wordt voldaan, maar dat de productowner het oneens is ‘hoe’ eraan wordt voldaan?
Acceptatiecriteria zoals hierboven laten voldoende ruimte voor evaluatie en bijstellen door user experience designer en key users. De duivel schuilt in de details, dus betrek hen erbij in voorkomende gevallen.
Dit sluit volledig aan bij mijn visie op requirements. Alleen merk ik in de praktijk dat idd de product owner (en nog wat andere “business stakeholders”) in de requirements documentatie het “hoe” ook graag terug wil zien om zo ook daarin een bepaalde controle te blijven uitoefenen.
Mijns inziens betekent dit dat het team nog erg ‘junior’ is ten aanzien van agile, ondanks dat er al jaren wordt gezegd dat we agile werken. Volgens mij is dit niet zozeer een requirements issue, maar betekent dit dat er een verandering binnen de team-mindset moet plaatsvinden.
Henri en Imgard, dank voor jullie reacties. Henri, de acceptatiecriteria zijn niet meer dan een hulpmiddel om gezamenlijk tot de gewenste software te komen of beter gezegd om gezamenlijk de business value te maximaliseren. Dus in de beschikbare tijd/budget zoveel mogelijk waarde leveren, is waar het echt om draait. Ik zou dat altijd voorop stellen.
Getrouwtrek klinkt niet goed, product owner oneens klinkt niet goed en product owner wil controle blijven uitoefenen klinkt ook niet goed. Ik ben het met Imgard eens dat er waarschijnlijk een verandering van de team-mindset nodig is. De waterval en wij-zij mindset blijkt (vaak ongemerkt) nog lang meespelen.
Ben net startend op dit gebied en ben blij met het uitgewerkte voorbeeld. Klopt het dat het niet zozeer een technisch verhaal is maar veel meer wat de gebruiker ervaart/zou moeten ervaren?
Ja Michel, dat heb je goed begrepen. Het zijn immers user stories en van oorsprong ook echt letterlijk verhalen van gebruikers.