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 het ontwikkelteam 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
Meeste reacties