User stories niet toereikend?

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 <gebruiker> wil ik <functionaliteit> zodat <meerwaarde>’. 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 ontwikkelteam 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 ontwikkelteam 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 requirements­techniek 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 meetings waarin business stakeholders en het voltallige ontwikkelteam de user stories bespreken. Het voltallige agile team is namelijk actief betrokken bij het uitwerken van user stories.

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap