Het doel is duidelijk: je wilt een product ontwikkelen dat een hoge toegevoegde waarde heeft voor klanten. Je wilt een resultaat bereiken waarmee teamleden en belanghebbenden tevreden zijn. Maar hoe bereik je dit doel? Hoe kun je in kleine, grondige stappen aan alle eisen van een product voldoen?
In Agile hebben user stories bewezen hiervoor een efficiënt hulpmiddel te zijn. Ze nemen je stap voor stap mee van het eerste idee naar een product dat klaar is voor de verkoop. Ik laat je zien wat user stories zijn, hoe je ze maakt en hoe je er je voordeel mee kunt doen.
Wat zijn User Stories in Agile?
De definitie van user stories in Agile beschrijft de vereisten van een product vanuit het oogpunt van de gebruiker. Met andere woorden, user stories vertellen je welke eigenschappen en functies een product moet hebben. Dit maakt ze tot een centraal hulpmiddel voor het bespreken en valideren van de behoeften van gebruikers en het werken aan de implementatie ervan met een gemeenschappelijk begrip.
User stories bieden een universele taal die teamleden, belanghebbenden en klanten begrijpen en spreken. In de praktijk betekent dit dat je user stories kunt gebruiken om een begrip van het door de klant gewenste product te ontwikkelen dat weinig ruimte laat voor misverstanden.
Meerdere user stories vormen samen een use case. User stories vinden hun oorsprong in Agile Software Ontwikkeling.
Hoe worden agile user stories gestructureerd?
User stories beschrijven de eisen en wensen voor een te creëren projectresultaat vanuit het perspectief van de klant of gebruiker. Agile user stories hebben deze elementaire structuur:
WHO (rol), wil WAT (doel/wens) WAAROM (toegevoegde waarde)?
Laten we de afzonderlijke onderdelen van user stories eens nader bekijken:
WIE (GEBRUIKER)
Je vult de WER placeholder met je klant of een typische vertegenwoordiger van je doelgroep. Hoe gedetailleerd je de WER beschrijft in de User Agile Story hangt af van de user story zelf en van de voortgang van het project. Wees daarom gedetailleerd genoeg om een zinvolle user story te maken.
WAT (FUNCTIE)
Hier plaats je de wensen van de gebruiker. Je kunt je afvragen wat de gebruiker verwacht of nodig heeft. Als je product zich nog in een vroege ontwikkelingsfase bevindt, kun je op basis van je ervaring aannames formuleren over welke functies de gebruiker verwacht. Als je al een vergelijkbaar product op de markt hebt, kun je de gewenste functies ook afleiden uit de feedback op dit product.
WAAROM (TOEGEVOEGDE WAARDE)
Alleen de toegevoegde waarde laat zien waarom een functie belangrijk is voor de gebruiker. Met de WHY kun je dus eerlijk nadenken over hoe goed je de eisen van een klant kent. Want: Het is gemakkelijk om een vereiste op te nemen in een user story, bijvoorbeeld omdat de klant aangeeft dat hij er behoefte aan heeft. Maar pas als je begrijpt waarom de klant het nodig heeft, heb je de context voor het implementeren van de eis. Pas dan kun je je afvragen of de suggestie/vraag van de klant op een efficiënte manier voldoet aan zijn echte behoefte – of dat er misschien een slimmere manier is. Laten we eens kijken naar een voorbeeld:
De klant wil een regencape om mee te fietsen. Je zou nu dus de eis "regencape" kunnen opnemen. Of je kunt de klant vragen waarom hij een regencape nodig heeft. Stel dat de klant antwoordt "Omdat ik niet nat wil worden".
Dit betekent dat je niet per se een regencape hoeft te leveren. Je kunt ook een fiets leveren met een geïntegreerd dak. Het belangrijkste is dat het de behoefte of het probleem van de klant – om niet nat te worden oplost. Hoe beter je het "waarom" begrijpt, hoe beter je je gebruikersverhaal kunt ontwerpen.
De meeste Agile Coaches gaan rond in cirkels....
...en oppervlakkige symptomen behandelen. Het is tijd om psychologie – te gebruiken voor een duurzame mentaliteitsverandering.
Wat zijn User Stories in Agile (voorbeeld)?
Je kent nu de afzonderlijke onderdelen van Agile User Stories. Een voorbeeld van een Agile User Story zou er zo uit kunnen zien:
Als KLANT Ik wil graag EEN VEILIG WACHTWOORD, ZODAT MIJN KLANTGEGEVENS BESCHERMD ZIJN.
Hier is de "KLANT". de gebruiker, "EEN VEILIG WACHTWOORD" de functie en "ZODAT MIJN KLANTGEGEVENS BESCHERMD ZIJN" de toegevoegde waarde.
Wat zijn User Stories in Scrum?
Als je in Scrum met user stories werkt, voeg je daar acceptatiecriteria aan toe. Acceptatiecriteria beschrijven de technische eisen waaraan user stories moeten voldoen op het moment van acceptatie. Met andere woorden: Acceptatiecriteria zijn de eisen die je nodig hebt om een user story waarde te laten creëren.
De betekenis van Agile user stories in de backlog kan meer gedifferentieerd worden. Want: In backlogs kunnen user stories niet alleen requirements beschrijven, maar ook een speciaal hiërarchietype vertegenwoordigen. Er zijn deze 3 hiërarchietypes:
Epos: Epics zijn breed gedefinieerde functionele gebieden van een product waarvan de concrete reikwijdte nog onduidelijk kan zijn.
Kenmerken: Kenmerken zijn specifieke prestatiekenmerken binnen een epic.
Verhalen: Stories zijn technische Agile user stories en user stories binnen een feature.
Je kunt deze hiërarchietypen binnen een sprint implementeren. Ze creëren een concreet voordeel voor de gebruiker.
Gebruikersverhalen schrijven – Hoe maak ik overtuigende gebruikersverhalen?
Om nuttige user stories te schrijven in agile projectmanagement zijn gedetailleerde gesprekken met alle belanghebbenden cruciaal. Deze moeten je een uitgebreid inzicht geven in de doelgroep en het te maken product. Hieruit kun je dan bijvoorbeeld persona's afleiden.
Daarnaast zijn de zogenaamde INVEST criteriaom een overtuigend gebruikersverhaal te maken:
Onafhankelijk: Een user story moet onafhankelijk zijn van andere user stories. Dit betekent dat de implementatie van een story niet mag vooronderstellen dat een andere story al eerder is geïmplementeerd. Dit heeft als voordeel dat je user stories op elk moment kunt prioriteren of verwijderen uit de backlog.
Laten we nog eens kijken naar het voorbeeld van de fiets. Stel dat je hebt besloten om een klein dakje over het zadel van de fiets te plaatsen in plaats van een regencape, zodat de klant niet meer nat wordt. Dat zou dus een user story zijn. Maar nu realiseer je je dat je voor een dakje eerst een stabieler zadel moet ontwikkelen waaraan het dakje kan worden bevestigd. Dat zou een andere User Story zijn. Beide Stories bouwen op elkaar voort. Dit is precies wat je moet voorkomen.
Natuurlijk is het soms onvermijdelijk dat je de ene user story voor de andere moet doen. Maar als algemene regel geldt: vermijd user stories waarvoor je eerst 20 andere user stories moet implementeren.
Bespreekbaar: Het schrijven van user stories kan soms best even duren – maar het moet daarna nog niet in steen gebeiteld zijn. Dat betekent: Product EigenaarStakeholders en ontwikkelaars moeten een user story altijd samen bespreken en verfijnen.
Waardevol: Het resultaat van user stories in agile projectmanagement moet toegevoegde waarde hebben voor de klant.
Inschatbaar: Met een overtuigend gebruikersverhaal kan het ontwikkelteam inschatten hoeveel moeite het zal kosten om het te implementeren.
Klein: Een user story moet zo "klein" zijn dat hij in één sprint kan worden gerealiseerd.
Toetsbaar: User stories in Scrum moeten testbaar zijn. Dit is de enige manier om te controleren of ze echt in de praktijk kunnen worden uitgevoerd.
Hoe je kunt profiteren van User Stories in Agile
Als je niet bekend bent met het schrijven van user stories in Agile, lijkt het misschien gewoon extra werk. User stories geven teams echter een belangrijke context voor hun taken, waardoor het belang van elke taak duidelijker wordt.
In principe is dit hoe je profiteert van User Stories:
Focus op de gebruiker: User stories zijn als een probleemgeoriënteerde takenlijst. Je team kan ze gebruiken om hun taken bij te houden en precies te weten hoe ze aan de behoeften van gebruikers moeten voldoen.
Holistische samenwerking: User stories laten alle betrokkenen in één oogopslag zien waar de dingen naartoe gaan. Op deze manier kan iedereen samenwerken en steeds opnieuw beslissen hoe de gebruiker een bijzonder hoge toegevoegde waarde krijgt.
Creatieve oplossingen: User Stories maken in flexibele softwareontwikkeling creatieve resultaten. Want: Ze laten teams kritisch nadenken over de beste oplossing voor het eindproduct.
Consistente successen: Elke User Story is een kleine uitdaging. Teams kunnen daarom na elk verhaal een klein succes vieren. Dit motiveert gedurende het hele ontwikkelproces.
Conclusie
User stories zijn een belangrijk hulpmiddel in het werk van agile teams. Ze laten steeds opnieuw in detail zien voor wie je wat ontwikkelt en waarom. Dit helpt je niet alleen om een product van hoge kwaliteit te maken dat is afgestemd op de doelgroep, maar ook om het team tijdens het hele proces gemotiveerd te houden.
Om succesvol te zijn op dit macroniveau van wendbaar werken, moet je organisatie als geheel wendbaar denken en functioneren. Om jou en je organisatie hierbij te ondersteunen, hebben we samengewerkt met gerenommeerde experts om het volgende te creëren Project Scagile ontworpen. Deze laat je in verschillende webinars zien hoe je een agile transformatie op de juiste manier aanpakt. De training is gratis. Neem gerust een kijkje!
Als je meer gevarieerde vragen wilt voor je retrospectieven, bekijk dan onze post over 32 nieuwe retrospective methoden & voorbeelden voor beginners en professionals (met onder andere de Mario Kart Retro, Marathon Retro en de Elon Musk Retro).
