Scrum Gids | 19. User Stories – wat zijn ze?

User Story is een korte beschrijving van een nieuwe productfunctionaliteit of een verbetering daarvan. Het bevat geen technische oplossing, maar behandelt vragen over de functionaliteit: Wie is de gebruiker? Wat doet het product? En wat is het doel ervan? De User Story beschrijft het product in alledaagse of zakelijke taal, hoewel het ook wijst op de taken van het Scrum Team die bedoeld zijn om de prestaties van het Team te verbeteren.

Wat zijn User Stories? – inhoudsopgave:

1. Inleiding
2. User Story. Van wie is het verhaal?
3. Hoe gebruik je User Stories?
4. Acceptatiecriteria
5. Samenvatting

Inleiding

User Story is de meest voorkomende manier om de taken die door het Scrum Team worden uitgevoerd te formuleren. Een enkele User Story definieert een kleine functionaliteit van het product. Het beschrijft het kleinste betekenisvolle, gedeeltelijke productdoel. Om deze reden zijn User Stories zeer kort.

User Stories worden gedurende de gehele tijd dat er aan het product wordt gewerkt, gemaakt. Ze worden continu gemaakt, vanaf het moment dat de beslissing om te beginnen met werken is genomen, tot de realisatie van het productdoel.

Het creëren van User Stories is een taak van de Product Owner. Op basis van een gesprek met een klant formuleert hij antwoorden op vragen die het mogelijk maken om een User Story te creëren en voert deze in het Product Backlog in. User Stories weerspiegelen echter niet alleen de behoeften van de klant.

User Story. Van wie is het verhaal?

Het Scrum Team creëert een User Story om de behoeften van de gebruiker te definiëren, en daarom wordt het in zakelijke taal opgeschreven. Met andere woorden, het geeft de voordelen aan die de implementatie voor de productgebruiker zal opleveren. In het Product Backlog kunnen er echter ook User Stories zijn die de behoeften van het Development Team beschrijven, bijvoorbeeld het verbeteren van de workflow tussen ontwikkelaars, of die de behoeften van de Product Owner beschrijven, bijvoorbeeld het organiseren van het Product Backlog. In dergelijke gevallen is de gebruiker in de User Story de ontwikkelaar en de Product Owner.

Je kunt een User Story beschrijven door de 3W-vragen te beantwoorden:

• Wie?
• Doet Wat?
• Waarom?

De User Story wordt dan in een formule weergegeven:

Als een [gebruikers type], wil ik [wat doen?] Omdat [waarom?].

Voorbeelden van User Stories over de functionaliteit van een online winkel geschreven in deze vorm zijn geïllustreerd in de onderstaande tabel:

Deze formule maakt het niet alleen mogelijk om een User Story te formuleren, maar ook om relatief eenvoudig technische taal om te zetten in zakelijke taal en omgekeerd. Hierdoor zien zowel ontwikkelaars als belanghebbenden duidelijk het doel en de fasen van de voortgang. We zullen ook het creëren van goede User Stories met behulp van de INVEST-methode in een apart artikel in de Scrum Guide-serie behandelen.

Hoe gebruik je User Stories?

Het creëren van een schematische User Story is slechts het begin. Ze zijn signalen en startpunten voor discussies over problemen en hun oplossingen. Het bespreken van User Stories vindt plaats tijdens de Sprint Planning om uit te zoeken welke technische kwesties het Development Team aan het Sprint Backlog zal toevoegen.

Typisch worden User Stories in de fysieke ruimte op kleine, gekleurde kaarten geschreven die op de werkplek zijn bevestigd. In de digitale ruimte werken digitale whiteboards, gedeeld door het Scrum Team, het beste.

Het opslaan van User Stories op deze manier heeft verschillende voordelen omdat:

• De autonomie van elke User Story benadrukt – elke heeft een apart kader en kan onafhankelijk van de anderen worden uitgevoerd
• De dynamiek van User Stories benadrukt – de volgorde van hun realisatie wordt opnieuw onderhandeld door het Scrum Team en de huidige volgorde van realisatie is zichtbaar op het bord dankzij de fysieke indeling van kaarten met User Stories
• Als herinnering dient – dankzij de visuele weergave van User Stories heeft het Scrum Team een wegwijzer in zicht om hen te herinneren aan het doel bij het creëren van gedetailleerde oplossingen.

Het Development Team schat de benodigde inspanning om een User Story te voltooien in dagen, manuren of Story Points.

Acceptatiecriteria

Een User Story moet bepaalde acceptatiecriteria hebben op het moment dat deze wordt geaccepteerd voor ontwikkeling door het Development Team. De acceptatiecriteria bepalen op welk punt het werk aan een User Story als voltooid kan worden beschouwd.

Op deze manier weten zowel de klant als de ontwikkelaars hoe hun werk zich vertaalt in zakelijke waarde. Typisch wordt een User Story als voltooid beschouwd wanneer de gebruiker die erin is gespecificeerd de beschreven actie kan uitvoeren. Neem met het bovenstaande voorbeeld een kijkje naar deze User Story met de inhoud:

Een klant kan met één klik een toverstok kopen.

Het is voltooid wanneer een werkende “Koop nu”-knop verschijnt op de pagina van de online winkel, die de standaard betalings- en verzendinformatie voor de ingelogde gebruiker gebruikt.

Samenvatting

Een User Story is een beknopte beschrijving van een nieuwe productfunctionaliteit of verbetering. Het dient als het kleinste doel dat in zakelijke taal is uitgedrukt, dat wil zeggen, vanuit het perspectief van de zakelijke waarde en de gebruiker. Het helpt om de taak die moet worden uitgevoerd en de criteria voor de voltooiing ervan duidelijk te definiëren.

Als je onze inhoud leuk vindt, sluit je dan aan bij onze drukke bijengemeenschap op Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.