User Story¶

In de wereld van Scrum is de User Story een belangrijk concept. Aan het begin van een Sprint worden de User Stories van een project gemaakt, tijdens een Sprint worden deze User Stories geïmplementeerd en aan het eind van een Sprint worden deze User Stories gepresenteerd. Je zou dus wel eens kunnen zeggen dat de User Stories de basis vormen van een Scrum project.

Wat is een User Story?¶

Een User Story is een korte, begrijpelijke beschrijving van waarde voor een gebruiker (of stakeholder). De beschrijving is:

geschreven in de taal van de gebruiker
gericht op doel en waarde (waarom), niet op de technische oplossing (hoe)

De standaardvorm is:

Als [type gebruiker] wil ik [doel/actie] zodat [waarde/reden].

Voorbeelden:

Als student wil ik mijn wachtwoord kunnen resetten zodat ik weer kan inloggen.
Als docent wil ik opdrachten kunnen beoordelen zodat studenten feedback krijgen.

Opbouw van een goede User Story¶

Een User Story bevat minimaal:

Titel: korte, actiegerichte samenvatting
Omschrijving: de standaardzin (Als … wil ik … zodat …)
Acceptatiecriteria: wanneer is dit echt klaar?
Taken: werkstappen voor het implementeren van de User Story

Acceptatiecriteria¶

Schrijf meetbare criteria vanuit gebruikersgedrag. Begin bij de happy path en voeg vervolgens randgevallen toe.

Voorbeeld bij “wachtwoord resetten”: - Er is een link “Wachtwoord vergeten?” op het login-scherm - Na invoer van een bestaand e-mailadres ontvangt de gebruiker een mail met resetlink - De resetlink verloopt na 60 minuten - Het nieuwe wachtwoord moet minimaal 12 tekens bevatten - Na succesvol resetten kan de gebruiker inloggen met het nieuwe wachtwoord

Je kunt ook Given-When-Then gebruiken (specifiek, testbaar):

Scenario: Wachtwoord resetten voor bestaande gebruiker
Gegeven dat ik op het login-scherm ben
En ik klik op "Wachtwoord vergeten?"
Wanneer ik mijn geregistreerde e-mailadres invul en bevestig
Dan ontvang ik een e-mail met een resetlink
En de link is 60 minuten geldig
En na het instellen van een nieuw wachtwoord kan ik inloggen

INVEST-principe¶

Gebruik INVEST om de kwaliteit van je User Stories te toetsen:

Independent: kan los van andere stories worden opgepakt
Negotiable: beschrijft behoefte, niet al een vaststaande oplossing
Valuable: levert zichtbare waarde op voor de gebruiker
Estimable: team kan de omvang inschatten
Small: past in één sprint (of kleiner); anders opsplitsen
Testable: acceptatiecriteria maken testen mogelijk

Definition of Ready (DoR)¶

Een story is “ready” voor de sprint als minimaal:

Omschrijving is in Als-wil-zodat vorm
Acceptatiecriteria zijn volledig en duidelijk
Grootte is klein genoeg (team-specifieke richtlijn)
Afhankelijkheden zijn bekend en beheersbaar
Design/schetsen en data/API-afspraken zijn beschikbaar (indien nodig)

Definition of Done (DoD)¶

Een story is “done” als minimaal:

Functionaliteit voldoet aan alle acceptatiecriteria
Code is gereviewd en gebouwd zonder fouten
Tests aanwezig en groen (unit/integratie/handmatig waar passend)
Documentatie en/of UI-tekst bijgewerkt
Geïntegreerd en gedemonstreerd tijdens de Review

User Stories opsplitsen (slim slicen)¶

Te groot? Splits op waarde, niet op techniek. Strategieën:

Workflowstap: bekijken → aanmaken → bewerken → verwijderen
Scenario: happy path eerst; randgevallen later
Data-varianten: simpel object → complexere velden/validaties
Platform: web eerst → mobiel later (alleen als zinvol)
Doelgroep: student → docent → admin

Voorbeeld splitsing “opdrachten beoordelen”:

Als docent wil ik opdrachten kunnen openen (lezen)
Als docent wil ik een cijfer kunnen invoeren (creëren)
Als docent wil ik feedback kunnen toevoegen (bewerken)
Als docent wil ik een beoordeling kunnen aanpassen (bewerken)

Relatie: Epics, User Stories, Tasks¶

Epic: groot thema (weken/maanden), niet sprint-klaar
User Story: concreet stukje waarde (sprint-klaar)
Task: werkstap voor het team (technisch/operationeel)

Voorbeeld:

Epic: Resultaten en feedback voor studenten
Story: Als student wil ik mijn cijfers zien zodat ik mijn voortgang kan volgen
Tasks: API endpoint bouwen, UI tabel maken, autorisatie instellen, tests schrijven

Wanneer: elke week (of 2× per sprint), 45–60 min
Wie: heel team (incl. Product Owner), optioneel stakeholder
Doel: stories verduidelijken, criteria aanscherpen, grootte grof inschatten, afhankelijkheden vinden

Tips:

Werk met voorbeelden/schetsen; teken samen
Beperk technische details in de story; zet die in tasks
Houd stories klein genoeg voor 1 sprint

Schatten: Story Points en Planning Poker¶

Story Points drukken relatieve inspanning/complexiteit uit (niet in uren)
Vergelijk met referentie-stories (bijv. 1, 2, 3, 5, 8, 13)
Gebruik Planning Poker om samen te schatten en verschillen te bespreken

Veelgemaakte fouten (en hoe te voorkomen)¶

Te technisch geformuleerd: schrijf vanuit gebruiker en waarde
Geen acceptatiecriteria: maak ze specifiek, testbaar
Te groot: splits op workflow/scenario’s
Oplossing vastspijkeren: laat ruimte voor ontwerp/implementatie tijdens de sprint
Randgevallen door elkaar: plan happy path eerst, daarna uitbreiden