• Product Owner

Zo zorg je dat User Stories wel duidelijk zijn

Herken je dit? Je bent al een tijdje lekker aan het scrummen. Het Scrum team is op elkaar ingespeeld, de samenwerking is goed. Maar je merkt dat items op de Product Backlog niet altijd even duidelijk zijn. Het is niet helemaal duidelijk wat er nou mee wordt bedoeld, en wat er mee bereikt dient te worden. Effect: sprints worden niet gehaald en de opgeleverde functionaliteit is niet helemaal wat beoogd werd. Hoe zorg je er nou voor dat items wel duidelijk zijn? Mijn tip: gebruik User Stories met heldere acceptatiecriteria!

User stories zijn een hulpmiddel om wensen voor een product op een korte manier te omschrijven, terwijl ook meteen de context geschetst wordt. Een goede User Story bevat voor wie de gewenste functionaliteit is, wat deze functionaliteit is en welke waarde dit oplevert voor de gebruiker. De User Story beschrijft de oplossing – het hoe – niet. De functie van een User Story is het geven van voldoende informatie van de wens om een dialoog aan te gaan en de uitwerking van de wens te faciliteren. Een “invitation to a conversation”.

Een veelgebruikt format voor user stories schrijven is:

Als [type gebruiker]
Wil ik [gewenste functionaliteit]
Zodat [verwachte waarde]

Met behulp van dit format beschrijf je snel voor wie, wat en waarom je iets wil gaan maken. Laten we kijken naar een voorbeeld:

Als websitebezoeker die geïnteresseerd is in een training
Wil ik een gave indruk van de training
Zodat ik hem zonder twijfel wil boeken

en:

Als klant in het bestelproces
Wil ik een alternatieve bezorglocatie kunnen opgeven
Zodat ik op mijn moment mijn bestelling kan ophalen

Acceptatiecriteria

Goed omschreven user stories vertellen ook hoe je weet dat wat je hebt gemaakt ook echt de wens van de gebruiker heeft vervuld. Meestal gebeurt dit in de vorm van acceptatiecriteria of een “how to demo”-statement. Acceptatiecriteria kunnen bijvoorbeeld opgenomen worden als simpelweg een lijst van criteria. Voor het eerste voorbeeld van een User Story hierboven zou dat kunnen zijn:

• ik zie een filmpje van de eerdere deelnemers waarin zij de training aanprijzen
• ik zie inspirerende foto’s van de trainingsruimte
• ik lees testimonials van enthousiaste deelnemers die de training eerder gevolgd hebben
• ik lees voorbeelden over de praktische toepassingen die ik leer

Een veelgebruikt alternatief voor een lijst van acceptatiecriteria is het Given-When-Then (GWT) format, dat meer context beschrijft. Het beschrijft voor een scenario de ingangssituatie (Given/Gegeven), de actie of gebeurtenis (When/Wanneer), en de uitkomst (Then/Dan). Dus:

Gegeven [ingangssituatie]
Wanneer [gebeurtenis]
Dan [uitkomst]

Laten we deze met behulp van de User Story van de alternatieve bezorglocatie van hierboven uitwerken:

Gegeven de klant is in het bestelproces
Wanneer wordt gevraagd om het adres van de locatie waarop bezorgd moet worden
Dan heeft de klant de mogelijkheid een ander adres dan zijn thuisadres op te geven

Een User Story kan meerdere scenario’s bevatten die in het GWT-format omschreven zijn. Op deze manier kan heel concreet het gewenste gedrag van de User Story beschreven worden.

Let op: een User Story is een vehikel voor effectieve samenwerking en uitwerking van gebruikerswensen. Het is geen duurzame documentatie; wanneer de User Story af is verdwijnt deze. Heb je toch documentatie nodig – bijvoorbeeld een handleiding – vat dit dan in een acceptatiecriterium of maak het onderdeel van je Definition of Done.