Kun jij goed uit de voeten met user stories? Of zijn ze voor jullie project toch te summier? De beschrijving van een user story is minder precies en bevat minder informatie dan we bijvoorbeeld gewend zijn in use cases of SMART requirements.
Een user story beschrijving is niet veel meer dan de standaardzin volgens het template ‘Als <type gebruiker> wil ik <functionaliteit> zodat <businesswaarde>’, met daarbij enkele acceptatiecriteria. Hier vind je een uitgewerkt voorbeeld.
Kunnen we daarmee wel uit de voeten?
Laten we eens kijken waar user stories allemaal voor gebruikt worden. We stellen ze tenslotte niet voor onszelf op.
User stories input voor …
De voornaamste activiteiten die user stories en requirements als input nodig hebben, zijn:
Requirements valideren
De business stakeholders moeten kunnen controleren of we hun wensen goed begrepen hebben. Een user story beschrijving geeft daarvoor wel een indicatie maar is niet specifiek genoeg. Er ontbreken nog allerlei informatie over de detailinvulling van de requirements.
Sprintplanning maken
Bij de start van een sprint bekijkt het agile team hoeveel en welke user stories ze in die sprint kunnen realiseren. Daarvoor moeten ze goed begrijpen wat de user stories inhouden. Ze hebben allerlei details nodig die niet in de beschrijving van een user story terug te vinden zijn.
Software realiseren
Een agile team implementeert iedere sprint een aantal user stories en levert productierijpe software op. Om dat voor elkaar te krijgen hebben ze heldere requirements nodig. Een user story beschrijving roept nog allerlei vragen bij ze oproepen. Er ontbreken immers voor de ontwikkelaars belangrijke details.
Systeem beheren
Na ingebruikname zorgen systeembeheerders ervoor dat het systeem goed blijft draaien. Gebruikerswensen en functionele wijzigingen lopen gewoonlijk via functioneel beheerders. Zij moeten voldoende inzicht in en overzicht over de systeemfunctionaliteit hebben. Die informatie kunnen ze onmogelijk uit de user stories halen.
Conclusie: Beschrijving user story niet toereikend
De conclusie is overduidelijk. Maar waarom zijn user stories dan zo populair? Waarom is het de aanbevolen requirementstechniek voor agile?
In de praktijk zie je vaak dat men naast user stories ook gebruik maakt van use cases. In een hybride (deels agile / deels traditionele) omgeving kan dat handig zijn. Maar vaak komt het ook voort uit gebrek aan kennis over de user story techniek en de agile aanpak.
User story techniek meer omvattend
Het is een misvatting dat een user story enkel bestaat uit een beschrijving. De zin ‘Als gebruiker wil ik …’ is nooit bedoeld geweest als de beschrijving van een user story. Het is alleen een geheugensteun.
Een user story omvat alle (detail) informatie en acceptatiecriteria die nodig zijn om hem te realiseren. Een groot verschil met traditionele requirements is dat maar een (klein) deel van die informatie wordt vastgelegd.
Achter de geheugensteun gaat een hele wereld schuil. Die wereld komt naar boven tijdens de sessies waarin business stakeholders en het voltallige agile team de user stories bespreken. Het voltallige agile team is namelijk actief betrokken bij het uitwerken van user stories.
Niet alleen achter de user story beschrijving maar ook achter agile requirements in het algemeen gaat een hele wereld schuil. Deze wereld ontdek je in het online programma Meester in agile requirements. Je leert daarin denken als een agile analist.
Nicole de Swart
