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.