Een handleiding voor het schrijven van gebruikersverhalen

Bij Moqod gebruiken we de Agile aanpak die erg gebruikersgericht is. Bij elk project richten we ons diep op de gebruikerspersoonlijkheid en het oplossen van zijn behoeften.

# Wat zijn gebruikersverhalen in Agile?

Het staat in de naam – gebruikersverhalen gaan allemaal over de gebruiker. Bij Moqod gebruiken we de Agile aanpak die erg gebruikersgericht is. Bij elk project richten we ons diep op de gebruikerspersoonlijkheid en het oplossen van zijn behoeften.

Gebruikersverhalen in Agile zijn eenvoudige beschrijvingen van een functie vanuit het oogpunt van een gebruiker. Het zijn een paar zinnen met minimale details en duidelijke taal die de gebruiker, zijn probleem en de oplossing beschrijven.

In Agile kunnen user stories een ander detailniveau hebben. Grotere verhalen (epics) kunnen worden opgesplitst in kleinere verhalen. Gebruikersverhalen beginnen meestal groot en op hoog niveau. Tijdens het proces en door iteraties worden ze steeds gedetailleerder.

Elk gebruikersverhaal, ongeacht de grootte, draagt bij aan de algemene waarde van het project.

# Formule voor gebruikersverhalen

Het standaardformaat van user stories bestaat uit drie delen:

Als gebruiker (user persona) …

Ik wil …

Zodat …

Het is de Agile versie van de journalistenformule ‘Wie, Wat, Waarom’. Door in te gaan op de details van de gebruikersverhalen trifecta, krijgen we het volgende:

Als gebruiker … Voor wie is de functie bedoeld? Wie is de gebruiker? Op dit punt hebben we onze eindklant geïdentificeerd en kunnen we hem duidelijk en beknopt beschrijven.

Ik wil … Wat is de bedoeling van de gebruiker? Hier komen we in de gedachten van de gebruiker: wat wil hij doen?

Zodat … Wat is de grote ‘pijn’ van de gebruiker? Wat is het uiteindelijke doel dat hij probeert te bereiken en het probleem dat hij probeert op te lossen?

Belangrijk: We schrijven gebruikersverhalen alleen vanuit het oogpunt van de gebruiker. We passen de actie van de gebruiker niet aan op wat we als functie proberen te implementeren. De manier om te begrijpen hoe de gebruiker denkt, is door Story Mapping toe te passen – het proces dat we in onze andere artikelen hebben beschreven.

De sleutel om de verhalen van gebruikers goed te krijgen, is door vanuit het oogpunt van de gebruiker te denken. Het is echter bijna onmogelijk om jezelf in de schoenen van de eindgebruiker te verplaatsen als je in je eentje een gebruikersverhaal probeert uit te werken. Dit is wanneer teamwork een rol speelt.

Met gebruikersverhalen kunnen al de belanghebbende partijen op dezelfde pagina komen en hun begrip van het proces delen.

# Voorbeeld van gebruikersverhalen

Met de bovenstaande formule kunnen enkele voorbeelden van hoe aangepaste verhalen kunnen worden toegepast, de volgende zijn: Waterfall model

• Als een fulltime werkend sportschoollid (gedetailleerde user persoon), wil ik een 24/7 sportschoolkaart zodat ik in het weekend kan trainen (het probleem van het niet kunnen werken tijdens de week oplossen)
• Als een rommelig persoon wil ik een schoonmaakservice-app zodat ik een schoonmaakster kan bellen als dat nodig is.
• Als georganiseerde student wil ik een digitale agenda met wekker zodat ik mijn tijd kan bijhouden en in sprints kan werken.

Aan het einde van het verhaal is er altijd een oplossing voor het probleem waarnaar een bepaald type gebruiker op zoek is. Het gebruikersverhaal beschrijft de voltooide taak voor de gebruiker: wat, niet hoe. Elk teamlid moet zijn verhaal schrijven met de oplossing voor het probleem van de klant in gedachten, zodat deze zichtbaar is voor de rest van het team.

Bij Moqod werken we zeer nauw samen met gebruikersverhalen en we leggen je graag verder uit hoe ze je project ten goede kunnen komen.

# Wanneer worden user stories geschreven tijdens het ontwikkelingsproces?

De stap die moet worden gezet voordat gebruikersverhalen worden samengesteld, is het definiëren van gebruikerspersonages. Kwaliteiten, demografie, geografische locatie, interesses, beroep, hobby’s, uitdagingen en pijnen – hoe dieper je gaat, hoe beter je de gebruikerspersoonlijkheid en zijn problemen begrijpt.

Omdat de gebruikersverhalen het mogelijk maken om het grote proces in kleinere delen op te splitsen, vindt de bijeenkomst voor het schrijven van verhalen meestal plaats aan het begin van het project. Dit maakt het mogelijk om het hele team vanaf de eerste dag op dezelfde pagina te krijgen.

In het begin is er echter geen beperking op het schrijven van alle gebruikersverhalen. Het mooie van de Agile aanpak is de mogelijkheid om terug te gaan en de sprint te herzien, feedback te krijgen, wijzigingen toe te voegen, het verhaal te bewerken (of een nieuwe te schrijven).

Nieuwe verhalen kunnen ook op elk moment door iedereen worden geschreven.

# Wat zijn de voordelen van de gebruikersverhalen?

Vanuit het oogpunt van ontwikkeling helpen gebruikersverhalen de functie duidelijk te definiëren, zodat deze begrijpelijk is voor de producteigenaar en elk teamlid. We zijn enthousiaste fans van gebruikersverhalen om vele redenen die elk onderdeel van het proces positief beïnvloeden.

5.1. Gebruikersverhalen zijn eenvoudig te maken en beschikbaar voor elke belanghebbende

De eenvoud van gebruikersverhalen maakt ze toegankelijk voor iedereen in het project. Iedereen die begrijpt hoe de user persona’s en de productaanpak werken, kan een user story schrijven.

De duidelijkheid van het gebruikersverhaal en de duidelijke taal maakt het begrijpelijk voor de andere partijen. Hierdoor kan iedereen bijdragen aan elk gebruikersverhaal om tot een verfijnd gebruikersgericht resultaat te komen.

Gebruikersverhalen helpen ook om de producteigenaar op één lijn te brengen met het team en uit te leggen waarom een bepaalde functie die hij in gedachten heeft niet meteen wordt geïmplementeerd.

5.2. Gebruikersverhalen zorgen voor een gedeeld begrip en voor duidelijkheid tussen teams

Door iedereen in dezelfde kamer vanaf het begin aan de user stories te laten werken, komt elke partij van het toekomstige product op dezelfde pagina. Gebruikersverhalen moedigen de deelname van elk lid aan. Ze dienen ook als een verbinding tussen degenen die de ideeën genereren en degenen die ze uitvoeren.

De ontwikkelaars en bedrijfsgeoriënteerde belanghebbenden spreken mogelijk een andere taal. Gebruikersverhalen stimuleren communicatie en transparantie tussen alle teamleden. Ze dienen als vertaler en als tussenpersoon waar beide partijen kunnen begrijpen wat de andere kant betekent.

Duidelijkheid en nauwkeurigheid aan het begin van het project besparen op de lange termijn tijd en geld.

5.3. Met gebruikersverhalen kan de geschatte werklast worden geëvalueerd

User stories zijn een onmisbaar onderdeel van de Agile aanpak. Werken in sprints waarbij elke sprint zich richt op een user story (of een deel daarvan) helpt bij het inzichtelijk maken van de workload voor de komende weken. De sleutel hier is om ervoor te zorgen dat het ontwikkelteam het einde van het gebruikersverhaal ziet, zodat ze kunnen inschatten hoeveel werk erin moet worden gestopt.

Daarom raden we ook aan om ervoor te zorgen dat de meeste gebruikersverhalen tijdens de sprint planning zijn besproken.

Met dit soort berekeningen verloopt de voortgang sneller en kan het team efficiënter werken.

5.4. Gebruikersverhalen helpen bij het prioriteren van de taken

Aan het begin van het project kunnen alle functies en gerelateerde taken belangrijk lijken. Ze zijn echter waarschijnlijk, het proces kan aantonen dat sommige ervan verouderd zijn, niet essentieel, of op het laatste moment kunnen worden uitgevoerd. Sommige van de wijzigingen kunnen optreden tijdens rapid prototyping, wat gebeurt na gebruikersverhalen.

Bepaalde functies zijn niet relevant en niet nodig in de planningsfase. Door gebruikersverhalen voorrang te geven wanneer / na het schrijven ervan, kan het team zich concentreren op wat er tijdens de eerste stappen moet worden geïmplementeerd en wat later kan worden opgepoetst.

5.5. User stories brengen de verbinding met de gebruiker tot stand

User-stories zijn een zeer gebruikersgerichte tool. Zoals we vaak zeggen: “Je bent niet je perfecte gebruiker”. De verbinding met de perfecte gebruiker vindt plaats door het hele team te laten deelnemen aan het project, feedback te verzamelen van daadwerkelijke gebruikers via rapid prototyping en de verhalen af te stemmen op echte gebruikers met hun problemen.

Deze verbinding is cruciaal als je het product aan gebruikers wilt verkopen, niet aan jezelf. Ze helpen ook om een stapje terug te doen en out of the box te kijken naar wat je misschien hebt gemist.

5.6. Gebruikersverhalen besparen op de lange termijn geld en tijd

Zelfs als het in het begin nauwgezet lijkt om aan elk gebruikersverhaal te werken, is het de moeite waard. Laten we het zo bekijken: je bouwt een huis. Bij elke laag kijk je of de stenen goed passen. Als dat niet het geval is, pas je ze aan, verwissel je de stenen of ga je graag verder met de volgende laag als dat wel het geval is.

Elke laag is hier een gebruikersverhaal. Kleine omwegen houden je geest scherp en je aandacht gefocust.

Een andere optie is dat je besluit om te kijken hoe het hele huis aanvoelt, eruitziet en gratis kost. Je ontdekt dat een van de lagen in het midden ongelijk is en de hele muur er slecht uitziet. Door terug te gaan om het repareren, zal je merken dat je een grotere rekening en veel verloren werkuren heeft. En een half huis om weer op te bouwen!

5.7. Met user stories wint de gebruiker altijd

Gebruikersverhalen, sleutelelementen van agile engineering, zijn een solide toverstaf als het gaat om het aanpassen van het product aan de perfecte klant. Met elk solide gebruikersverhaal en feedback erop, komt je team een stap dichter bij het product waarnaar je eindgebruiker op zoek is.