User story en user story mapping: zo werkt het

Wat is een user story

Wanneer je agile werkt of de scrum methodiek volgt kom je user stories en user story mapping tegen. Bij een user story gaat het erom om de behoefte van gebruikers zo goed, snel en vooral helder mogelijk scherp te krijgen. In dit artikel zoom ik verder in op user stories, leg ik uit hoe je user story mapping succesvol doet en geef ik je een software alternatief voor een user story template.

Laten we beginnen!

Wat is een user story binnen scrum en agile?

Een user story is een veelgebruikt model binnen agile werken en onderdeel van de scrum methodiek. User stories worden gebruikt om de beschrijving van een productfunctionaliteit vast te leggen vanuit het perspectief van de toekomstige gebruiker.

Net als de gehele scrum methode komen user stories en user story mapping van origine uit de softwareontwikkeling.

Vandaag de dag worden user stories voor veel verschillende productontwikkelingen gebruikt. Zeker niet uitsluitend bij softwareontwikkeling.

Daarnaast geldt bij userstories less is more. Een user story helpt om een vereenvoudigde versie van user requirements op te stellen.

In traditioneel projectmanagement is dit vaak een gigantisch document waarin de gebruikersbehoefte tot in de puntjes wordt gespecificeerd.

User stories zijn daarentegen kort en to the point.

Met goed uitgewerkte user stories kan de product owner de backlog vullen met relevante taken en de sprint iteraties plannen.

De kenmerken van een user story

User stories worden vaak uitgewerkt op Post-its of simpele kaartjes met dezelfde informatie erop:

  • Wie is de gebruiker? Normaal gesproken dit is de functie van de gebruiker, de klant of het type gebruiker.
  • Wat wil de gebruiker? Dit beschrijft welke functionaliteit de gebruiker wil.
  • Waarom wil de gebruiker dit? Dit geeft het doel van de gebruiker met de functionaliteit aan.

Verder kan je op de user story nog een unique identifier of een volgnummer toevoegen. Dat is wel handig in je projectorganisatie.

Ook kan je vaak een globale inschatting meegeven van de prioriteit of urgentie van de user story en hoeveel tijd en resources het om en nabij kosten. Dat helpt je om

Tenslotte zal per user story vooraf moeten worden aangegeven wat de aanvaardingscriteria zijn. Wanneer voldoet het ontwikkelde product of de functionaliteit voldoende om de story als voltooid te zien?

Wie is er betrokken bij user story mapping?

Wanneer je user stories maakt is het goed om dit te doen met een groep aan verschillende mensen.

Veelal worden er groepen gemaakt van 4 tot 8 mensen met daarin verschillende mensen die de gebruikers goed kennen (of de toekomstige gebruikers zijn), de product owner en mensen van het agile- of scrum team.

Ik zou willen zeggen: the usual suspects.

User story mapping, hoe werkt het?

Tot nu toe heb ik je uitgelegd wat een user story is en wat er ongeveer bij komt kijken om een kaartje uit te werken.

Maar hoe ga je nu op met de eindeloze hoeveelheden aan mogelijke wensen van gebruikers en allerlei (in jouw ogen) onlogische ideeën die naar je toe gesmeten worden door jouw potentiële gebruikers?

De totale exercitie om user stories te mappen voor een project leidt je tot een user journey. Dat is het grotere plaatje de user journey map.

Volg simpelweg de onderstaande 7 stappen voor user story mapping en je zorgt voor behoorlijk wat structuur in het proces:

  1. Zet een kader voor je user journey
  2. Creëer een “backbone”
  3. Identificeer en groepeer alles met gelijke doelen
  4. Verdeel grote taken in subtaken
  5. Vul de overgebleven gaten op
  6. Prioriteer alle taken
  7. Vat groepen taken in iteraties

Stap 1: zet een kader voor je user journey

Voordat je daadwerkelijk start met het in kaart brengen van individuele user stories schets je met elkaar een duidelijk kader.

Wat doet je product en wat doet het niet? Wanneer je het daarover eens bent, heb je al een erg sterk kader.

Het klinkt wellicht logisch. Het overkomt jou toch niet dat jij en je team elkaar verkeerd begrijpen?

Toch voorkom je zo dat je straks door de bomen het bos niet meer ziet.

Stap 2: creëer een backbone

In de eerste stap heb je kaders gegeven. Nu wil je de grootste en belangrijkste taken opschrijven. Dit mag “hoog over”. Dit is in principe de hele weg die je moet bewandelen uitgeschreven in taken op hoog niveau.

Het doel is dat je zo verschillende stappen kan onderscheiden die je later in detail verder kunt gaan mappen.

Voorbeeld: je wil online een vakantie kunnen boeken.

Dan zijn de stappen voor de gebruiker:

  • Binnenkomst op website
  • Selecteer een hotel
  • Controleer beschikbaarheid
  • Bevestiging en betaling

Later ga je de details invullen.

Deze stappen geven je echter een goede leidraad om verder mee te gaan. Je kan ze simpel visueel maken door ze van links naar rechts op een (digitaal) bord te hangen.

Hang de taken in logische volgorde en boven aan het bord. De ruimte eronder ga je straks gebruiken om deze taken verder uit te splitsen.

Stap 3: Identificeer en groepeer alles met gelijke doelen

Per grote taak zal je verschillende activiteiten gaan herkennen.

Een activiteit is een handeling waarvoor verschillende taken geregeld moeten zijn.

Om het voorbeeld van hierboven te volgen. Iemand moet om een hotel te boeken zich waarschijnlijk aanmelden.

Daarbij kom je een berg aan stappen tegen die met elkaar te maken hebben.

Denk hierbij aan het klikken op aanmelden om een account aan te maken, het invullen van gegevens, het bevestigen van een email en dergelijke.

Daarvan kan je dan een activiteit maken, die bijvoorbeeld gebruiker aanmelden heet. Zo krijg je een cluster van alle dingen die bij elkaar horen.

Stap 4: Verdeel grote taken in subtaken

Nu is het tijd om de grotere taken op te knippen in kleinere taken. Stel je voor dat een taak die nodig is om een email te kunnen bevestigen kan bestaan uit verschillende subtaken.

Zo kan je gericht delen in één sprint gaan oppakken. Je krijgt er nu dus een behoorlijke bak aan kaartjes bij als het goed is.

Elke activiteit (uit stap 3) en elke taak in je backbone (stap 2) kunnen opgeknipt worden in losse taakjes.

Stap 5: Vul de lege plekken in

Nu ben je een heel eind. Je hebt erg veel taken uitgewerkt. Probeer nu te testen of alles er is.

Loop alles door en doe dit onder verschillende scenario’s. Kan een gebruiker zijn weg vinden?

Het is helemaal niet gek om dit ook door mensen van buiten je team te laten doen. Je wil namelijk in je user story mapping zo compleet mogelijk zijn.

Stap 6: Prioriteer taken en subtaken (maar laat de backbone zoals hij is)

Nu kan je per gemaakte sectie alle taken gaan prioriteren. Schuif taken met een hoge prioriteit naar voren en met een lagere prioriteit naar onder.

Soms helpt het om een sectie verder op te splitsen in musthave’s en could have’s.

Ik raad je aan ook rekening te houden met onderlinge afhankelijkheden.

Echter, hoe je jouw map opstelt is een keuze die bij alle betrokkenen ligt.

Stap 7: Vat groepen taken in iteraties

Nu heb je als het goed is een berg aan taken die samen jouw user story maken. Het is allemaal redelijk op orde; alle grote taken zijn van links naar rechts te zien en alle subtaken zijn geprioriteerde en eronder te vinden.

Je kan nu eenvoudig de grote taken bij elkaar groeperen of beter gezegd opknippen.

Zo hou je sprint iteraties over waarbij elke iteratie een werkende versie van de functionaliteit moet opleveren.

Werk nu verder per segment het beoogde resultaat en de impact uit en you are good to go!

Welke software gebruik je voor een user story

Wanneer je een user story wil uitwerken, wil je het vooral simpel helder houden.

Persoonlijk heeft het mijn voorkeur om projectmanagement software hiervoor te gebruiken. Ik gebruik zelf Monday voor het maken van user stories en user journeys.

Dat vind ik handig, omdat ik daarna ook direct mijn sprint via hun Kanban bord inrichting kan starten. Ook de retrospectives kan je goed hierin bijhouden.

Het testen van Monday is gratis en wellicht kan je hier nog sneller verder mee dan met een user story template.

Acceptance criteria van een user story

Je wil – net als bij eigenlijk alle doelstellingen en taken – duidelijk afspreken wanneer iets af is.

In user stories gebruikt men hiervoor een lijstje van acceptance criteria.

Dat zijn simpelweg alle voorwaarden waar de release minimaal aan moet voldoen om de user story succesvol af te ronden.

Het hangt nogal af van de user story wat logische acceptance criteria zijn.

Wel kan ik je wat richting meegeven:

  • Elke user story heeft tenminste 1 acceptance criteria
  • De acceptance criteria moeten vastliggen voordat je begint met de implementatie
  • Het moet meetbaar zijn
  • Het moet een duidelijk wijze van acceptatie kennen (dus Go/Nogo)
  • Het moet gericht zijn op het eindresultaat

Stel je maakt een webshop en daarbij het je een user story om een “bedankt voor uw bestelling”-pagina te maken.

Een voorbeeld van een acceptance criteria kan dan de laadsnelheid van deze pagina zijn.

Je spreekt met elkaar dan af dat de functionaliteit (de pagina) pas af is wanneer het laden gemiddeld genomen minder dan “x” seconden kost bijvoorbeeld.

Voor het beheersen van acceptance criteria raad ik je ook aan om project management software te gebruiken, zoals Monday of andere agile project management software.

Verwar acceptance criteria overigens niet met de “Definition of Done“. Dit is een algemene checklist waar elk item of user story aan moet voldoen ongeacht de inhoud.

Een acceptance criteria is in principe uniek voor elke user story of kan uniek zijn.

Veelgemaakte fouten bij user story mapping

Alle veelgemaakte fouten komen eigenlijk voort uit het afwijken van alles wat hierboven beschreven staat.

Een aantal concrete voorbeelden van veelgemaakte fouten bij user story mapping:

  • Slecht uitgewerkte klantbehoefte
  • Geen backbone of rode draad
  • Niet alle user stories opgenomen
  • Geen duidelijke acceptance criteria
  • Slechte prioritering van taken
  • Geen heldere scope of kaders
  • Te weinig praten met je toekomstige users of te weinig onderzoek naar gebruik.

Komen deze fouten voor kan dit later leiden tot impediments binnen het scrum project.

Afsluitend: User stories zijn een krachtig middel om gericht te ontwikkelen

Samengevat helpen user stories je binnen het agile werken en de scrum methodiek om op gestructureerde wijze relevante functionaliteiten uit te plannen en te prioriteren.

Zorg dat je zo duidelijk mogelijk bent. Hier pluk je gezamenlijk met alle stakeholders later in het traject de vruchten van!

Mocht je vragen hebben over user story mapping of over bijvoorbeeld acceptance criteria of de inrichting van Monday voor user stories?

Laat dan gerust hieronder een berichtje achter.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *