Detaillering van user storiesDe mate van detaillering van user stories blijkt een van de belangrijkste punten waar analisten tegen aan lopen. Dat is te concluderen uit de vele reacties op het vorige artikel met 5 do’s and don’ts voor agile analisten.

Dat mensen worstelen met de mate van detaillering van user stories begrijp ik heel goed.

Extra lastig daarbij is dat het benodigde detailniveau situatie-afhankelijk is. Hoe beter business en IT op elkaar ingespeeld zijn, hoe minder details voorafgaand aan de sprint uitgewerkt hoeven te worden. En ook kunnen er voor de ene user story meer details nodig zijn dan voor de andere user story.

De mate van detaillering is minder belangrijk dan je nu waarschijnlijk denkt. In agile neem je immers 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.

Realiseer je dat

…het voor jou als analist niet te doen is om te bepalen welke mate van detail voor een user story vereist is.
Wat maar weinig mensen weten is dat het multidisciplinaire ontwikkelteam zelf de verantwoordelijkheid heeft om de benodigde informatie 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. De meeste ontwikkelaars hebben daar de hulp van een analist bij nodig.

Realiseer je dat

… 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 voorkomen.

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 te vroeg te 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 scrumteams) als momentopnamen.

Realiseer je dat

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

Realiseer je dat

… 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 de 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 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.

Je gaat je vanzelf meer richten op het gaandeweg steeds beter in beeld brengen van de werkelijke gebruikersbehoeften, als je bovenstaande punten goed voor ogen houdt. De juiste mate van detaillering van de user stories wordt dan minder belangrijk.

Laten we elkaar helpen door:

  • hieronder te delen in hoeverre jij je ‘gedwongen’ voelt om meteen de definitieve requirements in te veel detail vast te leggen? Welke stakeholders verlangen dat van je?
  • waar mogelijk jouw tips of ervaringen toe te voegen aan de reacties van collega analisten. Wat zou hem/haar kunnen helpen bij het detailleren van de user stories?

Ik ga uiteraard ook reageren met mijn tips.

Succes met de requirements,

Nicole de Swart

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

Met 25 do's en dont's 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:

Share This