User stories zijn een korte beschrijving van een product geschreven vanuit het perspectief van de eindgebruiker. Het kan het volgende bevatten: functies, functionaliteit, bugfixes, verbeteringsverzoeken, infrastructuurconfiguratie of technische documentatie. Het doel van een gebruikersverhaal is om uit te leggen hoe een functie waarde zal toevoegen aan de klant.
Een van de belangrijkste elementen van de Agile aanpak is dat mensen op de eerste plaats komen, en een user story plaatst de eindgebruiker in het middelpunt van de planning en uitvoering van een product. Deze verhalen zijn informeel en niet-technisch om het ontwikkelteam een realistische context te bieden. Het lezen van user stories moet het team een beter begrip geven van het product dat ze aan het bouwen zijn en de waarde die het creëert voor de gebruiker.
Over het algemeen helpen gebruikersverhalen het team om de focus van de gebruiker op hun dagelijkse werk te behouden, wat op zijn beurt samenwerking, creativiteit en een beter algemeen product stimuleert.
Wie is verantwoordelijk voor user stories?
Er is niet één persoon of rol binnen het Agile-team verantwoordelijk voor user stories. In feite kan iedereen die bij het project betrokken is gebruikersverhalen schrijven van de teamleden tot en met de belanghebbenden. Er worden echter veel verhalen geschreven tijdens een achterstand verfijning of sprintplanning bijeenkomst van het ontwikkelteam en de Product Owner.
Het is ook vermeldenswaard dat het veel minder belangrijk is wie het gebruikersverhaal schrijft dan wie er bij de discussies over betrokken is.
Hoe schrijf je gebruikersverhalen
Het volgende is handig om te overwegen bij het schrijven van user stories:
De definitie van gedaan:
Het is belangrijk om een duidelijk begrip te hebben van wat er nodig is om de user story to be Done te krijgen. Het verhaal kan als "voltooid" worden beschouwd zodra de eindgebruiker de geschetste taak kan voltooien (vaak aangeduid als Criteria of Satisfaction) en wanneer deze voldoet aan de overeengekomen normen (Definition of Done).
Feedback:
Samenwerken met gebruikers om het probleem of de behoefte in hun woorden vast te leggen. Het heeft geen zin om te raden wat ze willen.
Gebruik geordende stappen:
Schrijf een verhaal voor elke stap in het grotere proces of doel.
Gebruikerspersona's:
Een gedeeld begrip binnen het team van wie de eindgebruiker is en hun specifieke behoeften.
Stroom:
Als een story waarschijnlijk langer gaat duren dan de duur van een Sprint, moet het worden opgesplitst in kleinere stories of moet het worden beschouwd als een eigen 'Epic'. Het schatten van user stories is nuttig bij het beoordelen of stories verder moeten worden opgesplitst om een goede doorstroming van het werk te garanderen.
Zodra de gebruikersverhalen duidelijk zijn gedefinieerd, is het belangrijk om ervoor te zorgen dat ze zichtbaar zijn voor het hele team.
Sjabloon en voorbeelden voor gebruikersverhalen
User stories worden vaak geschreven op steekkaarten, sticky notes of als teams kiezen voor een digitale versie, online software. Een veelgebruikt sjabloonsjabloon is het volgende:
Als [type gebruiker] wil ik [een bepaalde functie] zodat [een bepaalde waarde].
Laten we dit nog verder opsplitsen:
- [Type gebruiker]: dit is precies wie het product en hun persona gebruikt. Het team moet een gedeeld begrip hebben van wie ze zijn en wat hun vereisten zijn.
- [Een doel]: hier wordt de intentie beschreven in plaats van een specifieke functie die ze willen gebruiken.
- [Een of andere reden]: Ten slotte is dit de reden waarom ze dit proberen te bereiken. Dwz Wat is het algemene voordeel dat ze proberen te bereiken? Wat is het grotere probleem dat moet worden opgelost?
Zo kunnen user stories er in de praktijk zo uitzien:
- Als [gebruiker] wil ik [mappen opgeven waarvan een back-up moet worden gemaakt] zodat [van mijn schijf geen back-up wordt gemaakt met mappen die ik niet nodig heb].
- Als [gebruiker] wil ik [mijn virtuele werkruimte organiseren] zodat [ik meer controle over mijn werk heb].
- Als [manager] wil ik [de voortgang van het team kunnen begrijpen] zodat [ik gemakkelijk kan rapporteren over successen en mislukkingen].
Ze hoeven deze structuur niet altijd te volgen, maar dit kan nuttig zijn bij het definiëren van de criteria van tevredenheid en de definitie van "Klaar".
[U kunt hier meer lezen over de Definition of Done in onze andere bronnen]
Waarom user stories maken?
We hebben onderzocht wat user stories zijn en hoe je ze kunt maken, maar het is ook belangrijk om te begrijpen waarom het creëren van user stories echt waardevol is voor teams. Voor ontwikkelteams die nieuw zijn in Agile, kunnen gebruikersverhalen soms een extra en onnodige stap lijken. Maar verhalen bieden het team nuttige context en associëren taken met de waarde die deze taken met zich meebrengen.
Enkele van de belangrijkste voordelen van gebruikersverhalen zijn:
- Verhalen stimuleren samenwerking. Het hebben van een duidelijk gedefinieerd einddoel kan het team in staat stellen om samen te werken aan hoe de eindgebruiker het beste kan worden bediend en dat doel kan worden bereikt.
- Verhalen helpen rollen te definiëren. Vanwege de beknopte en gebruikersgerichte aard van verhalen, kan het gemakkelijker zijn om uit elkaar te houden wie zich met wat bezighoudt en om rollen te definiëren.
- Verhalen zorgen voor dynamiek. Omdat het kleine werkeenheden zijn, kan het team regelmatig overwinningen vieren, wat helpt om momentum te creëren en te behouden.
- Verhalen stimuleren creatief denken. Verhalen helpen het team om creatief na te denken over hoe een einddoel het beste kan worden opgelost.
Samenvatting
Samenvattend is het duidelijk dat user stories een aantal behoorlijk substantiële voordelen opleveren. Door de eindgebruiker centraal te stellen in het werk en gesprek, wordt waarde gecreëerd door teams te helpen een succesvol product te bouwen en hen te motiveren om dit gaandeweg te doen. Verhalen verwerken en effectief inzetten is daarom belangrijk voor teams die Agile gebruiken.
