Blog

Goede user stories: de sleutel tot een succesvol scrumproject

07-11-2015

  1. Online Strategie
  2. Slim Werken
  3. Occhio

Over scrum hebben we inmiddels al aardig wat geschreven, en met ons vele anderen. Wij doen dat omdat we nog steeds heel enthousiast zijn over deze werkwijze en met name over het resultaat dat het oplevert. En nog belangrijker, onze opdrachtgevers zijn stuk voor stuk enthousiast wanneer ze bij ons voor het eerst in aanraking komen met de methode. Tijd om nu eens in te zoomen op de user stories die horen bij een scrumproject.

scrum

Wat verstaan we onder een user story?

Een user story is een korte beschrijving (een story) van wat een gebruiker (de user) wil kunnen. Wij zeggen in onze introductiemeeting altijd: “De user story is een kort op zichzelf staand scenario vanuit het perspectief van een gebruiker”. En deze wordt bij ons altijd bij voorkeur in een bepaald format opgeschreven, daar zo meer over.

Een user story formuleren

Een user story formuleren wij aan de hand van de volgende template:

Als [mijn rol] wil ik [behoefte of kans] zodat ik [resulterend vermogen]

Een aantal voorbeelden

  • Als klant wil ik gelijk het antwoord op mijn vragen kunnen vinden, zodat ik niet hoef te bellen of mailen
  • Als bezoeker wil ik altijd het hoofdmenu in beeld hebben zodat ik gemakkelijk kan navigeren door de site.

Daarnaast kan een story eventueel ook geformuleerd worden op de volgende wijze:

  • als [mijn rol] kan ik ?[resulterend vermogen].
  • [element / functionaliteit]

User stories moeten zo duidelijk geformuleerd worden dat ze ruimte overlaten voor interpretatie van de uitvoering, maar compact genoeg zijn te kunnen overzien en te begrijpen.

INVEST

Om aan bovenstaande te kunnen voldoen maken we gebruik van het ezelsbruggetje INVEST. Elke letter in het woord INVEST staat voor een eis aan de story:

Voorbeeld van een user story Voorbeeld van een user story

Independent (onafhankelijk) - een story moet zo min mogelijk afhankelijk zijn van andere, zodat makkelijk een prioriteit kan worden aangegeven

Negotiable (onderhandelbaar) - een story is geen geschreven contract, maar een ambitie om een behoefte te vervullen

Valuable (waardevol) - een story is waardevol voor eindgebruiker of klant

Estimable (inschatbaar) - er is genoeg kennis, van zowel techniek als het onderwerp, en de grootte van de story is te overzien

Hele grote stories worden soms "epics” genoemd. Deze epics bevatten stories gegroepeerd naar de volgorde waarop je het systeem zou uitleggen aan een onbekende.

Small (klein) - het kan ontwikkeld en getest worden binnen ½ dag tot twee weken door 1 of 2 ontwikkelaars

Testable (testbaar) - het is duidelijk wanneer een story is uitgevoerd / afgerond

Een kleine kanttekening: er zijn altijd elementen of functionaliteiten die zo duidelijk zijn, dat het onzinnig is om de template “Als [mijn rol] wil ik [behoefte of kans] zodat ik [resulterend vermogen]” te gebruiken. Doe dat dus ook niet. Meestal gaat het hier om vrij technische onderdelen. Denk bijvoorbeeld aan: de OTAP inrichting, of de basis HTML-template.

Waar in het scrumproject komen user stories tevoorschijn?

Een typisch scrumproject heeft de volgende kenmerken:

  • een project bestaat uit user stories;
  • deze user stories worden geprioriteerd en verdeeld over sprints;
  • een sprint is een deelproject van 2 weken;
  • een project is succesvol afgerond als alle geplande sprints afgerond zijn.

Ze komen voor het eerst tevoorschijn in sprint 0, daar waar de behoeftes voor het eerst geformuleerd worden.

Uit user stories volgen taken

De user story is zoals al aangegeven vooral bedoeld om de wensen te beschrijven, op zo’n wijze dat het scrumteam vervolgens een een schatting kan geven van de hoeveelheid werk die daarbij hoort. En daarvoor is overleg nodig. Wij plannen daar per sprint een meeting van een dagdeel voor in (de zogenaamde sprintplanning). Per story wordt met de product owner, de scrumteamleden en eventueel stakeholders in het project discussie gevoerd over wat de story nou inhoudt qua werkzaamheden.

Uit dit gesprek worden per story concrete taken opgeschreven die uitgevoerd zullen worden. Op deze wijze is iedereen het eens over wat er moet gebeuren. De verzameling van taken die behoren bij een user story kunnen vervolgens makkelijk worden ingeschat en zo wordt een bepaald hoeveel werk de betreffende story met zich meebrengt. Dit gebeurt net zo lang totdat er geen uren meer beschikbaar zijn in de beoogde sprint. Het inschatten van de story wordt gedaan met behulp van planning poker.

User stories zijn niet de enige onderdelen in de product backlog. Officieel heten alle items op de product backlog namelijk (je raadt het al): “product backlog items”. Het verschil zit hem in de formulering van het item wat bepaalt of we het hebben over een story of een product backlog item, maar voor het gemak spreken we in z’n algemeenheid altijd over user stories als we het over alle product backlog items hebben.

User stories & product backlog

Alle user stories samen vallen onder de product backlog. Dit is de lijst met items die je wilt uitvoeren. Tijdens de sprint wordt een deel van de stories van de product backlog overgeheveld naar de sprint backlog. Dit zijn nou precies de user stories die passen binnen de sprint(tijd) en waaraan in die betreffende? sprint gewerkt wordt.

Terug naar de user stories

Ze zijn dus eigenlijk een manier om de requirements beschrijven en hierin zegt men 'wie', 'wat', 'waarom' wil. Verder is het zo dat een user story weinig gedetailleerd is en past op een grote post-it.

En hier komt het succes om te hoek kijken. Als een story wordt geformuleerd wordt deze getoetst met het INVEST ezelsbruggetje. Kan de story geen antwoord geven op een van deze eisen, dan moet de story geherformuleerd worden.

User stories bepalen grotendeels het succes

Een scrumproject is niets zonder user stories. Met de titel verklapte ik het al: wij beschouwen ze als een van de allerbelangrijkste onderdelen voor succes in een scrumproject. Vergeet uiteraard ook niet een ervaren scrumteam, goede communicatie en plezier & toewijding in het project, maar de user stories kunnen voor een groot deel bepalen wat het verschil is tussen een slecht, een oke, of een heel goed uitgevoerd project. En daarom nog een aantal tips:

Nog een paar praktische tips

  1. Je kunt een aparte kleur gebruiken voor de post-its per type gebruiker / doelgroep. Zo maak je bijvoorbeeld direct goed onderscheid tussen de stories m.b.t. de websitebeheerder en de bezoeker.

  2. Omdat de story vaak toch een hele zin is, is het niet altijd in een oogopslag duidelijk wat het belangrijkste onderwerp van de story is. Onderstreep daarom de belangrijkste woorden, dan wordt dit wel direct duidelijk en dit helpt de leesbaarheid.

  3. Kies een groter formaat post-it dan het standaard vierkante blokje dat je kent; je hebt dan ten eerste meer ruimte voor de tekst en ten tweede kun je makkelijk onderscheid maken tussen de post-its met de taken die horen bij de story, want die zetten wij wel altijd op die vierkante post-its.

  4. Nieuwe stories - wensen die je echt voor het eerst hoort, en niet eerder in de briefing op ongeveer dezelfde wijze is benoemd - markeren we met een sterretje. Komen deze hoog op de priolijst, dan weet je dat dit ten koste kan gaan van andere (bekende) stories.

Tot slot: de product owner is de baas over de stories

Uiteindelijk is de product owner de baas over de product backlog en dus over de user stories. Dat wil zeggen dat zij of hij niet bepaalt op hoeveel werk een story wordt ingeschat, maar wel wat de prioriteit van de story is en of deze uberhaupt (nog) relevant is.

Meer weten over het uitvoeren van een scrumproject of het opstellen van user stories? Neem contact met mij op.

Eerder geschreven over scrum...

We hebben geschreven over wat je in ieder geval moet weten - de belangrijkste dingen (scrum in een notendop), waar scrum vandaan komt (Scrum - de vergelijking tussen rugby en (website)softwareontwikkeling), de rollen (Scrum & de teamrollen product owner, scrum master en development team), de verschillen tussen scrummen en de watervalmethode en hoe de sprint eruit ziet.

Wil je meer weten?

  • Reinder Stolte

    Bel of mail met Reinder voor vragen over nieuwe projecten, offertes, onze werkwijze of een eerste kennismaking.


    Reinder Stolte

    E
    info@occhio.nl

    T
    020 – 261 95 42 (algemeen)