Hoe je betere gebruikersverhalen schrijft met augurken (inclusief sjabloon)

User stories zijn een Agile techniek voor het definiëren van productfunctionaliteit en vereisten. Ze richten zich op het vertellen van een verhaal voor een actie die een gebruiker zal ondernemen en wat de verwachting is wanneer deze succesvol is. Het concept van user stories wordt veel gebruikt, maar het vertellen van goede verhalen kan behoorlijk lastig zijn.

User stories hebben de laatste jaren echter een beetje een klap gekregen, omdat ze te simpel zijn en geen inlevingsvermogen hebben in de gebruiker.

Goed nieuws – er is een betere manier! Ze heten augurken, maar in tegenstelling tot augurken zijn ze er niet om je leven te verzuren. (Tenzij je een augurkenliefhebber bent, denk ik!) 🥒

TL;DR

Als je een beetje haast hebt, is hier de TL;DR (hoewel ik je wil aanmoedigen om verder te lezen om toegang te krijgen tot de sjablonen!)

• Gebruikersverhalen richten zich op de gebruiker, niet op het product.
• Schets je persona’s om context toe te voegen.
• Voeg empathie toe aan je verhalen om acties en motivaties te begrijpen.
• Augurken: een betere manier om verhalen te schrijven.
• Gebruik augurken om te focussen op resultaten, niet alleen op output.

Wat zijn user stories?

User stories zijn korte, eenvoudige beschrijvingen van een oplossing die je team heeft bedacht, verteld vanuit het perspectief van de persoon die de interactie uitvoert. Ze maken deel uit van een groter epos dat het werkelijke probleem beschrijft dat moet worden opgelost en waarom je het oplost.

Het sleutelwoord hier is gebruiker, wat betekent dat een gebruikersverhaal de focus legt op de gebruiker, niet op het product.

Een user story richt zich meestal op drie gebieden:

• Als(wie)
• Ik wil(wat)
• Zodat(waarom)

Dit alles wordt meestal gevolgd door acceptatiecriteria, die bepalen hoe je weet of de interactie succesvol is.

Wie: Persona’s gebruiken om gebruikersverhalen te schetsen

Als je je gebruikers nog moet definiëren of begrijpen, dan zou je eigenlijk geen user stories moeten schrijven. Begin eerst met wat ontdekking, breng een klantreis in kaart en creëer relevante gebruikerspersona’s die je zullen helpen om deze verhalen verder te definiëren.

Een persona kan je helpen om de ‘wie’ van het gebruikersverhaal te begrijpen en van context te voorzien – met andere woorden, wie deze interactie uitvoert.

Dit is belangrijk omdat je onvermijdelijk te maken hebt met verschillende klantsegmenten, rollen en machtigingen, dus het is belangrijk om die interacties zo te definiëren dat ze geschikt zijn voor die verschillende soorten gebruikers.

Wat: interacties tussen gebruikersverhalen

Het ‘wat’ in een user story richt zich op de interactie zelf. Het lastige hier is om ervoor te zorgen dat je “wat” zich richt op wat de gebruiker moet doen, in tegenstelling tot wat de gebruiker wil doen, en dit is waar het typische verhaalsjabloon een beetje uit elkaar valt.

Om een beetje empathie aan het verhaal zelf toe te voegen, is het belangrijk om te benadrukken hoe de gebruiker zich zou kunnen voelen bij een bepaalde actie.

Niemand wil bijvoorbeeld een ingewikkeld wachtwoord invoeren met een hoofdletter, speciale tekens en een minimale lengte – maar ze weten dat ze dat wel moeten doen. In dit geval is het iets dat de gebruiker moet doen.

Waarom: De reden voor de actie van de user story

Het derde deel van het sjabloon voor gebruikersverhalen is het ‘waarom’ – dat wil zeggen, waarom de gebruiker een bepaalde actie wil (of moet) uitvoeren.

Terugkomend op ons vorige voorbeeld van het invoeren van wachtwoorden:

Als beheerder ben ik verplicht om een ingewikkeld wachtwoord aan te maken, zodat mijn account veilig is.

We begrijpen nu het wie, wat en waarom van het verhaal – maar er is een probleem. Het ontbreekt hier nog steeds aan inlevingsvermogen en context, want laten we eerlijk zijn, niemand wil dat ingewikkelde wachtwoorden een vereiste zijn, maar we willen allemaal veilige accounts.

Bij het testen hiervan zou het QA team simpelweg stoppen bij het controleren of het wachtwoord veilig is, niet of het proces frustrerend was voor de gebruiker.

Voer het Gherkin sjabloon voor gebruikersverhalen in

Augurkjes zijn een manier om toe te voegen aan user stories en een volledig scenario te geven dat ontwikkelaars en testers helpt om zowel de uitkomst als de output van een bepaalde gebruikersinteractie te begrijpen.

1. Scenario – het gedrag dat je gaat beschrijven
2. Given – de begintoestand van het scenario
3. When – een specifieke actie die de gebruiker onderneemt
4. Then – een toetsbare uitkomst, meestal veroorzaakt door de actie in When
5. And – dit gaat verder met een van de andere drie operaties indien nodig

Neem het eerder beschreven wachtwoordscenario:

1. Bij het instellen van een wachtwoord (Scenario),
2. Given dat ik een accountbeheerder ben,
3. WhenIk voer een wachtwoord in het wachtwoordveld in,
4. ThenIk zou gewaarschuwd moeten worden voor de wachtwoordvereisten,
5. And Ik zou meteen correcties mogen aanbrengen,
6. Then dat ik een beveiligde account kan maken.

We hebben nu een volledig beeld van wie de specifieke actie uitvoert en wat de vereisten zijn voor de acceptatiecriteria, en het team weet welke mogelijke frustraties er kunnen zijn zodat ze ervoor kunnen zorgen dat het proces soepeler verloopt.

Over het algemeen is de productmanager of producteigenaar verantwoordelijk voor het uitschrijven van de Gherkin-verhalen, waardoor een betere communicatie tussen de rest van het team ontstaat en iedereen zich richt op de resultaten en niet alleen op de output.

Wat zijn jouw favoriete manieren om verhalen te schetsen? Laat het me weten! ✌️