Hoeveel user story details? – 4 punten om je te realiseren

Het is een van de belangrijkste punten waar analisten tegen aan lopen: user story details uitwerken. Hoever moet je daarin gaan?

Het advies dat in agile vaak gegeven wordt is just enough en ook nog een just in time. Echt concreet is dat niet. Ik begrijp heel goed dat mensen worstelen met het uitwerken van user story details.

Wat het nog eens extra lastig maakt is dat de benodigde user story details situatieafhankelijk zijn. Hoe beter business en IT op elkaar ingespeeld zijn, hoe minder details voorafgaand aan de sprint uitgewerkt hoeven te worden (tenzij het management ze vereist). En ook kunnen er voor de ene user story meer details nodig zijn dan voor de andere user story.

Hoe bepaal je de benodigde user story details?

Het goede nieuws is dat de hoeveelheid user story details minder belangrijk zijn dan je nu waarschijnlijk denkt. In agile neem je namelijk de ruimte om de requirements en de ontwikkelde software voortdurend bij te stellen. Het is daarom niet de bedoeling om meteen de definitieve requirements en alle details vast te stellen.

Als je agile wilt werken is het belangrijk om je te realiseren dat:  

> Het voor jou als analist niet te doen is om te bepalen welke mate van detail voor een user story vereist is

Wat lang niet iedereen weet is dat het multidisciplinaire ontwikkelteam zelf de verantwoor­delijk­heid heeft om de benodigde requirements op tafel te krijgen. Zij weten het beste welke detailinformatie ze voor het realiseren van een user story nodig hebben.

Van het ontwikkelteam wordt dan ook verlangd dat ze actief betrokken zijn bij het achterhalen en scherpstellen van de user stories. Zij moeten meedenken en vragen blijven stellen totdat ze genoeg informatie hebben. Veel ontwikkelaars hebben daar de hulp van een analist bij nodig.

Helaas staan niet alle ontwikkelaars hiervoor open. Sommige ontwikkelaars blijven complete specificaties vragen en weigeren actieve betrokkenheid bij het uitwerken van user story details. Als jij ook met dit soort traditioneel denkende ontwikkelaars te maken hebt, zijn hier een aantal tips om hun betrokkenheid te vergroten.  

> Requirements en user stories slechts een momentopname zijn

De praktijk heeft ons geleerd dat veel requirements later nog wijzigen, zelfs bij een watervalaanpak waar je wijzigingen probeert te beperken.

Dat komt omdat je niet weet, en nog niet kunt weten, welke systeemondersteuning de business exact nodig heeft. Ook de business stakeholders kunnen dat nog niet precies weten, hoewel ze er soms wel een duidelijke mening over hebben.

In hybride (deels agile deels waterval) organisaties kom je er gewoonlijk niet onderuit om op voorhand behoorlijk veel details in de requirements op te nemen. Mijn advies is dan: doe dat zo laat en zo weinig mogelijk (zoek de grenzen op) én beschouw die requirements in ieder geval zelf (en binnen de agile teams) als momentopnamen.

> Voortschrijdend inzicht positief is

Voortschrijdend inzicht betekent dat je nu iets weet dat je voorheen nog niet wist. Je bent wijzer geworden, je hebt iets geleerd. In het geval van requirements heeft de business beter zicht op haar werkelijke (automatiserings)behoeften gekregen. Dat is dus positief.

Agile analisten doen er alles aan om de business te helpen achter hun werkelijke behoeften te komen. Dat doen ze door de stakeholders al vroegtijdig de reeds gebouwde software te laten uitproberen. Ze ervaren dan wat wel en wat niet handig werkt en welke functionaliteit verder nog noodzakelijk is.

> De ‘demo’ aan het einde van de sprint geen demo zou moeten zijn

In scrum vindt aan het einde van de sprint een ‘sprint review meeting’ plaats. In de praktijk wordt deze meeting vaak demo genoemd. Deze naam dekt echter niet de lading. En erger nog: met de naam demo geef je een verkeerd signaal af.

Demonstreren van het resultaat van de sprint is weliswaar onderdeel van de sprint review meeting, maar is zeker niet het belangrijkste onderdeel. De meeting is bedoeld om de gerealiseerde software te laten reviewen door de business. Vandaar de veelzeggende naam sprint review meeting.

Als je er het label ‘demo’ op plakt, wordt het al snel een demonstratie om verantwoording over het werk in de sprint af te leggen. Daarmee mis je het belangrijkste moment dat in scrum is ingebouwd om feedback van de business te krijgen.

Conclusie

Als je bovenstaande punten goed voor ogen houdt, ga je je vanzelf meer richten op het gaandeweg steeds beter in beeld brengen van de werkelijke gebruikersbehoeften. De hoeveelheid user story details worden dan minder belangrijk.

Je reactie, vraag of opmerking over dit artikel is zoals altijd meer dan welkom.

 

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