Scrum ontleed: hoe stel ik een goede user story en product backlog op?

In 2010 waren we een van de eerste Nederlandse bureaus die gingen werken volgens de projectmethodiek Scrum. En we willen niet meer anders. Waarom? Dat is simpel: onze projecten zijn sneller af, de samenwerking verloopt prettiger en de kwaliteit gaat omhoog. We krijgen van organisaties zonder Scrum-ervaring vaak vragen over Scrum. In een serie blogs geef ik hier, samen met mijn Scrum Master-collega’s, antwoord op. In dit blog zoom ik in op het schrijven van user stories het opstellen van de product backlog.

Tip: onderaan dit blog vind je een begrippenlijst van alle Scrum-termen die ik in dit blog gebruik. 

Laten we bij het begin beginnen, want wat zijn user stories en product backlogs en wat is hun ‘rol’ in een Scrum-project? Een Scrum-project bestaat uit meerdere Sprints van twee tot drie weken waarin een multidisciplinair team parallel aan elkaar een set van wensen oppakt. Deze wensen noemen we user stories: een specifieke wens op basis van een afgekaderde functionaliteit van het product. Alle wensen die in het product kúnnen komen, worden verzameld in een product backlog. Aan elke user story wordt een prioriteit en business value toegekend. Tijdens een Sprint worden de user stories op volgorde van prioriteit opgepakt. De product backlog is Sprint overstijgend: als er over 8 maanden weer een sprint wordt uitgevoerd, is de (herziene) backlog nog steeds het uitgangspunt. 

User stories schrijven

Elk Scrum-project begint dus met het schrijven van de user stories. Dit wordt gedaan door de Product Owner (PO). Indien nodig wordt hij hierbij geholpen door de Scrum Master. De PO is een afgevaardigde van de klant die onderdeel uitmaakt van het scrumteam en heeft belangrijke domeinkennis van de organisatie, de markt en het product. Dit gebruikt hij, samen met gesprekken met of input van stakeholders, als leidraad om de user stories te schrijven. Als het scrumteam of de Scrum Master de user stories zou schrijven, sluiten deze vaak niet aan op de business en werk je op basis van aannames. 

Hoe schrijf je een goede user story?

We spreken van een goede user story als deze volgens INVEST – een voor Scrum/Agile ontwikkelde maatstaf – is opgesteld. 

I – Independent 

De user story is onafhankelijk en zo gedetailleerd mogelijk. Het omschrijft een functionaliteit die onafhankelijk van andere functionaliteiten gerealiseerd kan worden. Tijdens een Sprint moeten de functionaliteiten los op te pakken zijn. 

N – Negotiable

De user story is niet, zoals bij traditionele projecten, volledig voorgedefinieerd. Het is een omschrijving van een wens, niet van de oplossing. Je omschrijft wat je gaat bouwen, maar niet hoe je dit technisch gaat realiseren. Dat laat je aan het development team over. Zij hebben de vrijheid om een user story naar eigen inzicht zo optimaal mogelijk te realiseren. 

V – valuable

Een belangrijk onderdeel van een user story is de business value. De waarde van een functionaliteit wordt in een getal uitgedrukt. Een functionaliteit kan geld creëren en daardoor veel business value hebben, maar het hoeft niet om geld te draaien. Stakeholdermanagement kan ook een reden zijn om veel waarde en prioriteit aan een user story toe te denken. Ditzelfde geldt bijvoorbeeld voor een functionaliteit die zorgt voor tijdsbesparing. De PO bepaalt de business value.

E – Estimable

De omvang van de user story moet kunnen worden ingeschat, zodat de complexiteit kan worden ingeschat. Tijdens de Sprint Planning wordt de complexiteit van de user stories ingeschat, zodat kan worden bepaald welke wensen tijdens de Sprint gerealiseerd worden.
S – Small
De user story moet klein genoeg zijn om binnen een Sprint te kunnen realiseren. Vaak geldt: hoe groter de wens is, hoe complexer de realisatie is. Kleinere functionaliteiten zijn makkelijker in de schatten en te testen. 

T – test

De user story is testbaar. zodat kan worden vastgesteld dat de user story afgerond – in Scrum-termen ook wel ‘done’ genoemd – is. Het development team, de PO en stakeholders moeten precies weten wat de user story inhoudt en waarop deze beoordeeld wordt met testen. Dit wordt verder uitgelegd in de definition of done. 

En – in ieder geval in onze ogen – misschien wel het belangrijkste: de user story is altijd vanuit de persona geschreven. De eindgebruiker moet het product gebruiken en dus snappen. Het product moet opleveren wat en werken zoals de eindgebruiker verwacht, anders heeft het product geen toegevoegde waarde.

Een voorbeeld… 

Stel je gaat een webshop met verschillende producten van verschillende merken bouwen. Het kenmerk van je persona is dat hij altijd een specifiek merk koopt. De persona wil op een specifiek merk kunnen filteren, zodat de productweergave makkelijk en snel wordt aangepast naar zijn persoonlijke wensen. Je stelt de volgende user story op: 

“Als bezoeker wil ik kunnen filteren zodat ik mijn product vind.” 

Deze user story voldoet niet aan INVEST, is niet vanuit de persona geschreven en is heel erg breed. Het roept vooral vragen op. Hoe wil je filteren? Hoe moet de interactie eruit zien? Hoe komen de filters tot stand? Waar worden de filters beheert?

Om een user story die vanuit de persona is geschreven en independent, negotiable, valuable, estimable, small, testable is, moet je de filter functionaliteit opsplitsen in meerdere user stories, zoals:

“Als oriënterende bezoeker wil ik snel product Y met eigenschap X naar voren kunnen halen zodat ik mijn gewenste product eenvoudig kan vinden.”

De user stories worden na de start van een Sprint niet meer aangepast. Er worden dus geen nieuwe wensen opgepakt in een lopende sprint. Een nieuwe wens moet opnieuw worden ingeschat en dat heeft impact op de Sprint goal – een korte omschrijving van wat het scrumteam in de komende sprint wil bereiken – die tijdens de Sprint Planning door het team is vastgesteld. Een nieuwe wens kan wel worden toegevoegd aan de backlog en – indien deze veel business value heeft – worden opgepakt in de volgende Sprint. 

De product backlog opstellen

Als de user stories zijn geschreven, worden deze op de product backlog gezet. De product backlog wordt opgedeeld op basis van de business value. De user story met de hoogste business value staat bovenaan en die met de laagste onderaan. Dit wordt doorgaans aangegeven met een cijfer tussen de 100 en 999. De PO kijkt hierbij bijvoorbeeld naar de Return on Investment en de persona. 

Vervolgens wordt de backlog met het team gedeeld en vindt de product backlog refinement plaatst. Tijdens de refinement worden de user stories aangescherpt, zodat tijdens de Sprint Planning de complexiteit kan worden ingezet.

Meer weten over Scrum?

Volg ons gratis webinar ‘Scrum voor beginners’ en leer in één uur alle ins en outs van Scrum.

Begrippenlijst

  • Product backlog | De verzameling van alle wensen die in het product kunnen komen. Deze wensen (user stories) hebben een unieke prioriteit op basis waarvan ze tijdens de sprint worden opgepakt. 
  • Persona | Een fictief persoon die een doelgroep vertegenwoordigt. Om ons zo goed mogelijk in de klant te kunnen verplaatsen, maken we persona’s. Denk aan naam, foto, leeftijd, online ervaring, branchegerichte kenmerken, gezinssituatie, etc.
  • Product Owner (PO) | De afgevaardigde van de klant die bij het team op kantoor zit. De PO kan ter plekke knopen doorhakken en vragen beantwoorden en houdt zo de vaart erin. Het is daarom belangrijk dat de PO hiervoor van zijn of haar organisatie voldoende tijd en mandaat krijgt.
  • Scrum Master | De Scrum Master dient de PO en het (ontwikkel)team. Hij coacht, faciliteert, motiveert en verwijdert belemmeringen in het project en/of voor het (ontwikkel)team. Daarnaast is de Scrum Master ervoor verantwoordelijk dat Scrum wordt begrepen en goed wordt toegepast. 
  • Sprint | Een periode van twee tot drie weken waarin een multidisciplinair team een set van wensen (user stories) oppakt.
  • Sprint goal | Een korte omschrijving (een of twee zinnen) van wat het scrumteam in de komende sprint wil bereiken.
  • Sprint Planning | Scrum-event waarmee elke sprint begint. Tijdens de Sprint Planning bespreekt het scrumteam welke wensen worden opgepakt, hoe die gerealiseerd worden en hoe complex het realiseren van elke wens is.
  • User story | Eén specifieke wens op basis van een afgekaderde functionaliteit.

Medewerker foto
Scrum Master & BI Consultant Hugo Leijdekkers

Hugo heeft meerdere rollen, waaronder technisch project management, BI consultant en Scrum Master. Resultaatgericht, loyaal en oplossingsgericht omschrijven hem als persoon. Een van zijn drijfveren is het conceptueel uitdenken tot het realiseren van een project, dit binnen de randvoorwaarden. In zijn vrije tijd reist en sport hij graag en is Hugo altijd in voor een borrel!

Over Hugo Leijdekkers