Tips voor het slicen van user stories

Het maken van goede user stories voor een scrum team is voor veel product owners een uitdaging. Hier zijn enkele tips voor het splitsen of slicen van user stories. de tips komen uit een webinar dat scrum-uitvinder Jeff Sutherland gaf samen met Ellen Gottesdiener.

De product owner (PO) is een van de drie rollen uit scrum. De Product Owner bepaalt alleen de richting: Hij of zij bepaalt waar het team aan werkt (de product backlog) en hoeft zich niet bezig te houden met hoe het team werkt. Het werk van een product owner is complexer dan het in eerste instantie lijkt. Een goede product backlog opstellen en bijhouden vergt niet alleen het vertalen van de wensen van de klant naar gedetailleerde user stories, maar ook het op de hoogte zijn van vaak technische mogelijkheden om deze wensen te realiseren. Naast een breed spectrum aan kennis en kwaliteiten moet de PO ook in staat zijn om goed te luisteren naar de betrokken partijen (klanten, developers, management) zodat wensen en oplossingen optimaal samen worden gebracht in een geprioritiseerde backlog.

Wat is een goede user story

Tijdens een recent webinar getiteld Slicing User Stories gingen Jeff Sutherland (CEO van Scrum Inc. en mede-bedenker van Scrum) en Ellen Gottesdiener (agile consultant via EBG Consulting) dieper in op de technieken die een PO tot zijn of haar beschikking heeft om user stories goed te krijgen. Wat bedoeld wordt met goed vatten zij als volgt samen:

• user stories moeten duidelijk zijn: onduidelijke stories zijn moeilijk te testen, en de waarde ervan voor het eindproduct is moeilijk in te schatten;
• user stories moeten niet te groot zijn: als stories regelmatig niet binnen een sprint af zijn worden ze vaak meegenomen naar de volgende sprint. Dit kan het leerproces enorm vertragen;
• en tenslotte, niet te veel user stories: vele tientallen of zelfs honderden tot in detail uitgewerkte stories op de product backlog leiden tot frustratie en onnodige overhead.

You want to get ready so you can get done — Jeff Sutherland

Conversations are optimized when they are structured — Ellen Gottesdiener

Het schrijven van goede user stories draait om keuzes maken (optioning) en waarde toekennen (value), aldus Gottesdiener. Een PO verzamelt en bedenkt mogelijkheden, en filtert daar vervolgens de juiste mogelijkheden uit.

Het slicen van user stories met zeven dimensies

Slicing is een methode om zowel de verschillende mogelijkheden, als de waarde daarvan, op een gestructureerde manier in kaart te brengen. Centraal hierin staan zeven product dimensies:

1. gebruiker: mensen en apparaten die iets doen met het product
2. interface: de manieren waarop interactie plaatsvind
3. acties: de mogelijkheden die het product biedt voor een gebruiker
4. data: de informatie die het product nodig heeft of aanbiedt
5. regels: beleid waar het product aan dient te voldoen
6. omgeving: zowel de hardware, als de fysieke locatie waar het product wordt gebruikt
7. kwaliteit: de (meestal) meetbare criteria zoals beveiliging, bruikbaarheid of testbaarheid

Het onder de loep nemen van een user story vanuit elk van deze zeven dimensies stelt een PO in staat om de kennis van het team te benutten, en tegelijkertijd de waarde van bepaalde keuzes aan het team te communiceren. Samenwerking tussen PO en andere partijen is hierbij onontbeerlijk: het doel van het werken met user stories is niet de uitgeschreven user story, maar het gesprek dat ontstaat. Door het gesprek zijn de waarde en de details van de story voor iedereen duidelijk.

Voorbeeld van user story slicing

We nemen de user story:

• Als een klant wil ik een product kunnen kopen zodat ik dit kan gebruiken.

Vanuit het aspect gebruiker kunnen we de gebruiker klant beter specificeren. Het blijkt dat het hier kan gaan om zowel nieuwe als bestaande klanten, en dat klanten bedrijven kunnen zijn maar ook particulieren. Vervolgens bepaalt de product owner, op basis van zakelijke, technische en klantgerichte overwegingen, dat de meeste toegevoegde waarde ligt bij nieuwe zakelijke klanten. Bij de product dimensie interface wordt opnieuw een aantal mogelijkheden gegenereerd (betalen met cash, pinnen, factuur sturen via e-mail als fax) waarna de product owner de beste selecteert. De oorspronkelijke user story wordt geëvalueerd aan de hand van de overige product dimensies, en als volgt herschreven:

• Als een nieuwe zakelijke klant (gebruiker) wil ik een nieuw boek (data) met contant geld kunnen kopen (acties) zodat ik dit kan lezen. 

Verdere details kunnen ook nog aan het backlog item worden toegevoegd:

• Prijs moet worden gecontroleerd, totaalprijs moet worden berekend (acties)
• Valuta moet vooraf bekend zijn (regels)
• Transactie vind plaats in de winkel (omgeving)
• Er wordt handmatig contact afgerekend, een printer drukt het bonnetje af (interface)
• Het printen van het bonnetje mag maximaal 3 seconden duren (kwaliteit)

Met een dergelijke gedetailleerde user story kunnen product owner en team aan de slag met het opstellen van duidelijke acceptatie criteria. Door de developers te betrekken bij de conversatie begrijpen ze de details, kunnen ze gerichter en sneller werken en zullen ze eerder opleveren wat het meeste waarde heeft voor de klant.

Meer informatie

Voor wie meer wil weten over de basis van scrum raden we het agile manifesto aan en geven we ook cursussen Scrum for Management, Scrum Foundation en vervolgworkshops. Eerder schreven we over de retrospective, agile contracten en zelfsturende teams. Meer informatie over Slicing is in het artikel Slicing requirements for agile success.