Een user story is een korte beschrijving van een wens, vanuit het perspectief van de gebruiker: wie wil iets, wat wil hij en waarom? Agile teams gebruiken user stories om werk klein, begrijpelijk en waardevol te houden. De story is geen volledige specificatie, maar het begin van een gesprek.
Wat is een user story?
User stories komen uit Extreme Programming, een Agile-werkwijze uit eind jaren negentig. Ze worden veel gebruikt in Scrum, maar de Scrum Guide schrijft ze niet voor. Een user story is een veelgebruikte manier om een item op de Product Backlog te beschrijven. Het is dus niet hetzelfde als een Product Backlog Item: een backlog kan ook andere items bevatten, zoals een technische verbetering of een bug.
De bekendste vorm stamt uit 2001 en is in de afbeelding bovenaan dit artikel te zien:
- Als [soort gebruiker]: wie heeft er baat bij?
- wil ik [iets kunnen doen]: wat wil die gebruiker?
- zodat [waarde]: waarom, wat levert het op?
Het “zodat” wordt vaak weggelaten, maar is het belangrijkste deel. Het vertelt het team waarom de wens er is, zodat het ook een betere oplossing kan voorstellen dan gevraagd.
Voorbeelden
- Als nieuwe klant wil ik me kunnen registreren, zodat ik mijn bestellingen kan terugzien.
- Als online shopper wil ik mijn zoekresultaten filteren op prijs, zodat ik snel producten binnen mijn budget vind.
- Als teamleider wil ik een overzicht van de doorlooptijd per week, zodat ik zie of onze verbeteringen effect hebben.
Card, Conversation, Confirmation
Ron Jeffries vatte de user story in 2001 samen in drie woorden:
- Card: de story past op een kaartje. Hij is bewust kort.
- Conversation: de details komen uit het gesprek tussen de Product Owner, het team en de gebruikers, niet uit een dik document.
- Confirmation: acceptatiecriteria leggen vast wanneer de story af is. Bij het voorbeeld over filteren: je kunt een minimum- en maximumprijs invullen, de resultaten passen zich direct aan, en het filter blijft staan als je doorklikt.
Wanneer is een user story goed?
Bill Wake bedacht in 2003 het ezelsbruggetje INVEST: zes kenmerken van een goede user story.
- Independent (onafhankelijk): los van andere stories op te pakken, zodat de volgorde vrij te kiezen is.
- Negotiable (bespreekbaar): een begin van een gesprek, geen contract. De uitwerking ligt nog open.
- Valuable (waardevol): levert iets op voor de gebruiker of de organisatie. “Database aanpassen” is geen user story.
- Estimable (schatbaar): het team kan inschatten hoeveel werk het is.
- Small (klein): past ruim in één sprint. Is een story te groot, dan splits je hem, bijvoorbeeld per soort gebruiker, per stap in het proces of in een eenvoudige en een uitgebreide versie.
- Testable (testbaar): je kunt vaststellen of hij af is.
Wie schrijft de user stories?
Iedereen kan een user story schrijven: de Product Owner, het team of een stakeholder. De Product Owner is wel verantwoordelijk voor de Product Backlog en bepaalt de volgorde. De Developers bepalen hoe ze een story uitvoeren. Zo blijft het gesprek gaan over wat de gebruiker nodig heeft, en niet over hoe het team zijn werk moet doen.
Een goede manier om te beginnen is een user story workshop: alle betrokkenen schrijven samen stories. Het levert vaak veel stories op, ook dubbele of varianten op hetzelfde thema, en vooral interessante gesprekken. Daarmee heb je een eerste Product Backlog én betrokken stakeholders.
Tot slot
User stories zijn geen verplichting, maar wel heel handig. Ze houden de gebruiker in beeld, maken werk klein en bespreekbaar, en maken het eenvoudiger om te beoordelen of het geleverde werk klopt.
Wil je meer weten over user stories en de Product Backlog? Bekijk de Product Owner-training.