Als een gebruiker X wil ik zus en zo kunnen zodat ik dit en dat kan bereiken, is toch al bijna de perfecte User Story? Veel mensen denken dat een User Story alleen bestaat uit bovenstaande zinsconstructie. En dat gebruik van die zinsconstructie voldoende is om er voor te zorgen dat een project het juiste “Agile’ resultaat oplevert.

Hieronder een aantal tips waarmee je er voor kan zorgen dat, User Storys ook zo geïnterpreteerd worden als dat je bedoelt had:

1. Een perfecte User Story kun je herkennen aan een korte naam. Een korte naam zorgt ervoor dat je de User Story gemakkelijk kan vinden en blijft hangen. Een korte naam zorgt er ook voor dat je goed een discussie kan voeren over de verschillende User Stories op de backlog. Daarnaast zorgt een korte pakkende naam ervoor dat je in een oogopslag inzicht krijgt in de gewenste functionaliteit van een (sprint)backlog.

2. Gebruik de “Als X wil ik zus en zo, zodat ik dat en dat” als inleiding van de context van de gewenste functionaliteit. Het gebruik van deze zinsconstructie zorgt er voor dat de gewensten functionaliteit ook voor iemand toepasbaar is. Niks is zo zonde al functionaliteit ontwikkelen waarvoor niet duidelijk is wie het in welke situatie waarom gaat gebruiken of waarvoor.

3. Voeg additionele context toe in de vorm van een korte beschrijving. Bijvoorbeeld wat achtergrond informatie over de situatie waarin de User Story een rol speelt. Daarnaast kan het inzicht geven in  wat er in het grotere geheel bereikt wordt en wat je verwacht van de functionaliteit.

4. Maak datgene dat bereikt moet worden kwantitatief, zodat je het resultaat achteraf kan meten, bijvoorbeeld in termen van tijdswinst, kosten besparing. Kwantitatief maken zorgt er ook voor dat je dus achteraf eenduidig kan bepalen of de implementatie een succes was. Meten is weten!

5. Voeg acceptatie criteria toe, zodat duidelijk is waar de User Story aan moet voldoen, niet alleen functioneel maar ook non functioneel. Gebruik hierbij bijvoorbeeld FURPS zodat de non functionele requirements niet vergeten worden.

6. Geef acceptatie criteria een unieke kenmerk zodat je ze makkelijk kan hergebruiken in andere User Stories. Dat scheelt niet alleen werk, maar zorgt er ook voor dat alle users stories dezelfde criteria hebben, ook als er iets veranderd.

7. Beschrijf welke gegevens en dus data noodzakelijk is bij het uitvoeren van de User Story. Zo krijg je meteen inzicht in eventuele privacy issues en of er noodzaak is voor koppeling met andere systemen.

8. In een perfecte User Story is duidelijk welke impact op andere systemen verwacht kan worden. Breng in kaart op welke applicaties en systemen de User Story invloed heeft. 

9. Maak een overzicht van de keuzes, architectuurprincipes en of ontwerp beperkingen die van invloed kunnen zijn op de User Story. Zodat je eerdere discussies niet nog een keer hoeft te voeren.

10. Maak een use case diagram zodat in een oogopslag duidelijk is welke rollen, systemen en functionaliteiten een rol spelen in de user story.