User story uit een interview: sjabloon en acceptatiecriteria

Een user story beschrijft de waarde voor de gebruiker

Een user story beschrijft kort het gewenste resultaat vanuit het perspectief van degene die het product gaat gebruiken. Een gangbare vorm is ‘Als [rol] wil ik [handeling], zodat [voordeel]’. Dat opent het gesprek over de behoefte. De eisen en de toetsing moeten nog worden uitgewerkt.

‘Voeg een groene knop toe’ is een voorstel voor een oplossing. Om de story te schrijven moet je weten wat iemand wil doen en wat er in de huidige werkwijze in de weg zit. Bewaar de uitspraak om je interpretatie te controleren.

Een user story schrijven vanuit een interview

1. Kies een concreet voorval

   Zoek de beschrijving van de laatste echte situatie. Wie deed wat, met welk materiaal en met welk doel? ‘Iedereen heeft rapporten nodig’ biedt te weinig grond voor een aparte story.

2. Noteer de exacte uitspraak en context

   Bewaar de tijdcode en enkele omliggende zinnen. Houd de woorden van de geïnterviewde apart van je eigen conclusie. Laat uitzonderlijke situaties herkenbaar als uitzondering.

3. Formuleer rol, handeling en voordeel

   De rol moet de situatie verduidelijken, voorbij de algemene aanduiding ‘gebruiker’. De handeling moet waarneembaar zijn en het voordeel moet uitleggen waarom die persoon de handeling nodig heeft.

4. Controleer de afbakening

   Kies één afgerond en nuttig resultaat dat je apart kunt bespreken en testen. Breng de hele route van registratie tot jaarrapport niet onder in één story.

5. Voeg acceptatiecriteria toe

   Leg vast onder welke voorwaarden het gewenste gedrag aantoonbaar werkt. Neem het hoofdscenario en een belangrijke uitzondering op. Stem de criteria met het team af voordat je ze als klanteis behandelt.

6. Breng open vragen opnieuw ter sprake

   Als rollen en rechten, gegevensvolume of uitvoerformaat onbekend zijn, noteer de vraag expliciet. Vul de leemte niet op met de gebruikelijkste implementatie.

Van uitspraak van de coördinator naar storykaart

Het voorbeeld gaat over een fictief notitiesysteem. Het beschrijft geen bestaande functies van Transkribator. De behoefte is een geselecteerd fragment delen zonder overtollige informatie. De kleur van een eventuele knop is een ontwerpkeuze.

De bron is vastgelegd, maar het belang voor de meeste klanten is nog onbevestigd. Eén opname laat één ervaring zien. Bepaal de prioriteit afzonderlijk met aanvullend bewijs, productdoelen en de uitvoeringskosten.

Een user story onderscheiden van een lijst technische taken

‘Maak een databasetabel’ en ‘voeg een eventhandler toe’ zijn technische taken. Ze kunnen bij de uitvoering van de story horen, maar verklaren de gebruikerswaarde niet. Een fraaie zin volgens het sjabloon garandeert ook niet dat het team alle beperkingen begrijpt.

Vertel de story aan een tester zonder een interfaceonderdeel te noemen. Kun je niet beschrijven wat de persoon voor en na de wijziging doet, ga dan terug naar het interview. Test ook de negatieve gevallen: geen geselecteerde gegevens, te weinig rechten of een nieuwe poging. Kies alleen de relevante uitzonderingen, zodat de kaart geen specificatie van het hele product wordt.

Kaart met bron en open vragen

Titel van de story:
Rol en werksituatie:
Als [wie] wil ik [handeling], zodat [voordeel].

Bron: interview / datum / tijdcode:
Oorspronkelijke uitspraak:
Onze interpretatie:

Acceptatiecriteria:
1. Bij [voorwaarde] kan de persoon [handeling] en krijgt die [resultaat].
2. Als [belangrijke uitzondering], volgt [verwacht gedrag].

Buiten de scope van de story:
Nog te verduidelijken:
Wie bevestigde de formulering en wanneer:

• De rol is concreet en het voordeel duidelijk.
• Het citaat staat los van de oplossing van het team.
• De criteria zijn door observatie te toetsen.
• Vragen blijven herkenbaar als vragen.