
Hoeveel requirements (details) moet ik vastleggen in agile? Dit is denk ik de vraag die ik het meest krijg. Het is een lastige vraag, want er is geen eenduidig antwoord op te geven. Net als veel andere dingen in agile is het situatieafhankelijk. Het is onder andere afhankelijk van de volwassenheid van het agile team en van hoe de afstemming met de business is vormgegeven.
Ik snap dat 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 en heb daarom een voorbeeld uitgewerkt.
Voorbeeld

Voor het uitwerken van een voorbeeld was ik huiverig, omdat het vaak meer vragen oproept dan het beantwoordt. Toch ben ik na aanhoudende verzoeken overstag gegaan. Ik heb geprobeerd voldoende context te geven om het voorbeeld over te brengen. Beheerdocumentatie heb ik niet meegenomen in dit voorbeeld.
Context
Een opleidingsinstituut gespecialiseerd in in-company cursussen is een portal aan het ontwikkelen. Hiermee kunnen HR-managers de competenties van hun medewerkers en sollicitanten toetsen om zo eventuele kennishiaten te identificeren. De portal krijgt een databank met meer dan duizend vragen. Het opleidingsinstituut gaat de portal gratis beschikbaar stellen aan haar grote klanten.
Naast een epic over het afnemen van de toetsen, heeft het opleidingsinstituut ook de volgende epic (heel grote user story) onderkend:
Als HR-manager wil ik (potentiële) medewerkers aan een toets onderwerpen, zodat ik eventuele kennishiaten kan identificeren en ons opleidingsaanbod daarop kan aanpassen.
Deze epic is in backlog refinement sessies besproken. De product owner en het ontwikkelteam zijn daarbij samen op onder andere de onderstaande user stories uitgekomen (uitleg user stories). Ze hebben ook schermschetsen en foto’s van het whiteboard gemaakt.
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.
User stories
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. Als het opleidingsinstituut wil uitproberen of het concept en de vragen in de databank aanslaan, kunnen ze de portal na deze user story alvast beschikbaar stellen aan (een beperkt aantal) klanten. Het moet dan wel mogelijk zijn om de toetsen te printen, zodat ze handmatig ingevuld en nagekeken kunnen worden.
2. Toetsresultaten zien
Als Opleidingsmanager wil ik de resultaten 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.
3. Toetsverzoeken

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 en de verzending moet bevestigen.
- 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 aangegeven medewerkers het verzoek mailt’ is onnodige ballast, (tenzij je het gebruikt als een traditionele afvinklijst ).
4. Medewerkersgroepen definiëren
Als Opleidingsmanager wil ik een groep met medewerkers definiëren, zodat ik ze vervolgens in 1 keer kan verzoeken om de toets te maken.
- Testen met groepen van 0, 1, 200 en 1.001 personen.
N.B. Neem vooral minimum- en maximumwaarden en foutieve waarden op.
5. Toetsen zoeken
Als Opleidingsmanager wil ik zoeken in de bestaande toetsen, zodat ik kan bepalen of ik er 1 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 ga ervan uit dat het idee zo wel duidelijk is.
Laat me hieronder even weten of dit voorbeeld je geholpen heeft.
Succes met de requirements,

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.
Gratis e-book ‘Vliegende start als agile analist’


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?
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.