User stories schrijven (met voorbeelden en acceptatiecriteria)

Een user story is een korte beschrijving van een functie vanuit het standpunt van de gebruiker: „Als [type gebruiker] wil ik [doel] zodat [reden].” Daaronder schrijf je acceptatiecriteria: een paar specifieke voorwaarden die waar moeten zijn voordat de story als af geldt. Houd elke story klein genoeg om in één keer te bouwen en te testen, en schrijf de criteria zo dat iedereen ze kan controleren.

User stories werden populair bij agile softwareteams, maar ze zijn net zo nuttig als je zelf bouwt met een AI app builder. Een goede story is een goede prompt.

Het formaat

Een user story heeft drie onderdelen:

Als [wie], wil ik [wat] zodat [waarom].

• Wie is een specifiek soort gebruiker: een eerste bezoeker, een betalend lid, een receptioniste van een kliniek, een beheerder. Niet „de gebruiker”.
• Wat is het ding dat ze willen doen, in hun eigen woorden. Niet hoe het scherm werkt.
• Waarom is het resultaat waar ze om geven. Dit is het deel dat mensen overslaan, en het deel dat voorkomt dat je het verkeerde bouwt.

Voorbeeld:

Als sportschoollid wil ik een lesboeking annuleren vanaf mijn telefoon zodat iemand op de wachtlijst mijn plek kan innemen en ik geen no-show-kosten betaal.

Het „waarom” vertelt je twee dingen die het „wat” niet zei: het moet op een telefoon werken, en de wachtlijst- en kostenregels spelen mee.

Acceptatiecriteria

Een story zegt wat er gewenst is. Acceptatiecriteria zeggen wanneer het af is. Ze moeten specifiek genoeg zijn dat twee mensen het erover eens zouden zijn of elk criterium slaagt.

Een gangbare manier om ze te schrijven is Gegeven / Wanneer / Dan:

• Gegeven een beginsituatie
• Wanneer de gebruiker iets doet
• Dan is dit het resultaat

Voor de sportschool-boekingsstory:

1. Gegeven dat ik een boeking heb die meer dan 12 uur weg is, wanneer ik op Annuleren tik en bevestig, dan wordt de boeking verwijderd en zie ik „Boeking geannuleerd”.
2. Gegeven dat ik een boeking annuleer en de les een wachtlijst heeft, wanneer de annulering is opgeslagen, dan krijgt de eerste persoon op de wachtlijst de plek en een e-mail.
3. Gegeven een boeking die minder dan 12 uur weg is, wanneer ik op Annuleren tik, dan zie ik dat er een kosten voor late annulering gelden voordat ik bevestig.
4. Gegeven dat ik op een scherm van telefoonbreedte zit, dan is de knop Annuleren zichtbaar zonder zijwaarts te scrollen.

Een gewone checklist werkt ook, zolang elk punt testbaar is. „Annuleren is makkelijk” is niet testbaar. „Annuleren kost maximaal twee tikken vanaf de boekingenlijst” wel.

Stap voor stap: een goede story schrijven

Stap 1: Begin bij een echte gebruiker en een echt probleem

Kies één type gebruiker en iets waar die vandaag mee worstelt. Heb je klantgesprekken gevoerd, gebruik dan hun woorden. „Ik vergeet altijd op te zeggen en word belast” is een beter startpunt dan „voeg annuleringsfunctie toe”.

Stap 2: Schrijf de story in één regel

Vul het template in. Als je geen overtuigend „zodat” kunt schrijven, vraag dan of de functie überhaupt nodig is.

Stap 3: Voeg drie tot zes acceptatiecriteria toe

Dek eerst het belangrijkste succesgeval, daarna de belangrijke variaties: een andere rol, een lege staat, een limiet, een fout. Schrijf je er meer dan zes, dan is de story waarschijnlijk te groot.

Stap 4: Noteer wat buiten scope valt

Één regel bespaart veel heen-en-weer: „Buiten scope: terugbetalingen voor betaalde lessen; beheerders die annuleren namens leden.” Zo groeit de story niet terwijl je bouwt.

Stap 5: Toets hem aan INVEST

INVEST is een gangbare checklist voor goede stories. Een story moet zijn:

Je hoeft niet elke story te scoren. Het is het nuttigst als een story niet goed voelt en je wilt weten waarom.

Goede en slechte voorbeelden

Hoe je een te grote story splitst

Grote stories zijn waar projecten vastlopen. Gangbare manieren om te splitsen:

• Op gebruikersrol. Leden annuleren hun eigen boekingen; personeel annuleert elke boeking.
• Op stap in de flow. Lessen bekijken; een les boeken; een herinnering krijgen.
• Eenvoudig geval eerst. Een gratis les nu annuleren; kosten en terugbetalingen in een latere story.
• Op datavariatie. Eerst één locatie ondersteunen, later meerdere.
• Happy path, dan fouten. Eerst laten werken, daarna de afhandeling toevoegen voor volle lessen, verlopen strippenkaarten, enzovoort.

Elk stukje moet nog steeds iets zijn dat een gebruiker kan gebruiken en merken.

User stories gebruiken als prompts

Een user story met acceptatiecriteria is erg dicht bij een goede prompt voor een AI app builder. Hij geeft de AI het wie, het wat, het waarom en een definitie van klaar. Stuur één story per bericht:

Als sportschoollid wil ik een lesboeking annuleren vanaf mijn telefoon zodat iemand op de wachtlijst mijn plek kan innemen. Acceptatiecriteria:

1. Annuleren staat bij elke boeking in Mijn boekingen, met een bevestigingsstap.
2. Annuleren meer dan 12 uur voor de les verwijdert alleen de boeking.
3. Minder dan 12 uur ervoor: toon „Een kosten voor late annulering van $5 is van toepassing” voordat je bevestigt, en leg de kosten vast bij de boeking.
4. Als de les een wachtlijst heeft, krijgt de eerste persoon de plek en een e-mail.
5. Werkt op een scherm van telefoonbreedte. Buiten scope: terugbetalingen, personeel dat namens leden annuleert. Bouw dit, controleer daarna elk criterium in de preview en vertel me welke slagen.

Je kunt de AI ook vragen user stories op te stellen uit een ruw idee, en die daarna zelf bewerken:

Hier is mijn app-idee: [twee of drie zinnen]. Schrijf de user stories voor een eerste versie, gegroepeerd per type gebruiker, elk met 3 tot 5 Gegeven/Wanneer/Dan-acceptatiecriteria. Markeer welke essentieel zijn voor de lancering en welke kunnen wachten.

Lees het resultaat altijd na en bewerk het. De AI kent je gebruikers niet; jij wel.

De acceptatiecriteria dienen ook als je testplan. Wanneer de story is gebouwd, loop je elk criterium zelf na. Onze gids over je app testen voor de lancering bouwt hierop voort.

Waar user stories passen tussen andere documenten

• Een productvereistendocument beschrijft het hele product: het probleem, de gebruikers, de scope. User stories zijn de gedetailleerde onderdelen erin. Zie hoe schrijf je een PRD met AI.
• Een bugrapport beschrijft iets wat kapot is ten opzichte van een story die al gebouwd was. Zie hoe schrijf je een goed bugrapport.
• Een MVP is de kleinste set stories die de kernwaarde levert. Zie wat is een MVP.

Veelgemaakte fouten

• „Als gebruiker…” Te vaag. Noem het echte type gebruiker.
• Het „zodat” overslaan. Zonder reden kun je geen verstandige afwegingen maken.
• De oplossing schrijven in plaats van de behoefte. „Ik wil een keuzelijst” legt een ontwerp vast voordat iemand heeft nagedacht.
• Criteria die niet testbaar zijn. „Makkelijk”, „snel” en „intuïtief” zijn wensen, geen criteria.
• Stories die eigenlijk epics zijn. „Mijn account beheren” is tien stories.
• Alle stories vooraf uitschrijven. Schrijf de volgende paar uitgebreid uit; houd de rest als one-liners tot je er bent.

Stories in Mythex

In Mythex is de modus Plan een goede plek om een idee in stories om te zetten: de agent bespreekt de aanpak voordat hij iets bewerkt. Als een story klaar is, schakel je naar Bouwen en plak je hem, één story per bericht. Daarna kan /test in de preview doorklikken en de flow controleren, en kun je elk antwoord met Terug naar dit punt terugdraaien als het de verkeerde kant op ging. Zie effectieve prompts in de documentatie, en onze gids over prompts schrijven voor AI app builders.

Checklist user stories

• Noemt een specifiek type gebruiker
• Beschrijft een behoefte, niet een ontwerp
• Bevat een echt „zodat”-motief
• Heeft drie tot zes testbare acceptatiecriteria
• Dekt minstens één randgeval of fout
• Benoemt wat buiten scope valt
• Klein genoeg om in één keer te bouwen en te testen
• Criteria na het bouwen één voor één gecontroleerd

Veelgestelde vragen