Kleinere user stories zijn beter

In de waterval project methode, waar mensen in werkten voordat ze agile gingen werken maakten we een ontwerp van een feature en dat schreven we helemaal uit. Een document van meerdere pagina’s waarin alles beschreven stond wat we nodig hadden van het nieuwe stuk software.

Later is men overgegaan op agile werken. Wat eigenlijk overblijft is het grote document. Natuurlijk is het document netjes opgeknipt in brokjes werk, die we nu user stories noemen. Het blijkt echter, dat het nog steeds lang duurt voordat zo’n brokje werk af is om voor de klant beschikbaar te maken.

Een release duurt vaak nog lang en na een release komen meerdere bevindingen bovendrijven, die direct opgelost moeten worden in een hotfix of pas in de volgende release opgelost worden (wat nog even duurt).

Meerdere redenen

Waarom dit gebeurt heeft meerdere redenen: het hele release proces is eigenlijk niet meegenomen in de agile transformatie, de klant is er niet echt klaar voor of buiten de Scrum teams is er nog steeds een waterval gestuurd proces met Go/No go momenten.

Op deze processen heeft een agile team niet direct invloed. We kunnen ons hier dus wel druk over maken, maar het is beter om dat aan de organisatie te laten. We hebben wel invloed op een andere reden en dat is de grootte van de user stories.

Waarom kleinere user stories?

Er zijn meerdere redenen waarom je als Scrum team user stories kleiner wil maken dan dat ze nu zijn. Een greep hieruit:

• Het reduceert risico’s doordat je een kleiner stukje software bewerkt en het risico in minder lijnen van code zit.
• Je krijgt sneller feedback, ook als het niet op productie staat kun je al werkende software aan je klant laten zien en daar feedback op krijgen.
• Het is makkelijker om de prioriteit aan te passen, omdat je minder lang in één user story bezig bent.
• Je hebt meer te vieren: elke 1 tot 2 dagen kun je minimaal 1 user story opleveren.

Hoe kan ik user stories kleiner maken?

Er zijn verschillende manieren om user stories kleiner te maken, of eigenlijk op te delen in meerdere kleine user stories. Enkele voorbeelden:

• Splitsen op soort gebruiker
• Splitsen op business rules
• Splitsen op test case
• Eerst het “happy path” maken

Door bijvoorbeeld eerst het happy path te maken, kan de gebruiker al zien hoe het werkt en direct feedback  geven. Je weet dan als team of je het juiste aan het maken bent, of dat je het nog moet aanpassen. Daarna weet je dus dat je goed zit en kun je de andere “path’s” makkelijk afmaken met de feedback van de gebruiker.

Tips voor kleinere user stories

Als je begint met het opsplitsen van user stories, houdt dan onder andere de volgende zaken in de gaten:

Gebruik INVEST

Gebruik INVEST om de criteria van jouw user story goed te bepalen. Dit staat voor:

• Independent – onafhankelijk van andere user stories.
• Negotiable – er is ruimte om over de inhoud te praten en aan te passen.
• Valuable – alleen deze user story opleveren levert al waarde aan de klant.
• Estimable – we hebben een idee hoeveel moeite dit gaat kosten.
• Small – het is binnen een korte tijd te realiseren.
• Testable – we weten dat de kwaliteit goed is, als het door de klant gebruikt wordt.

Dit zorgt ervoor, dat je alle informatie hebt, maar ook dat je user stories niet TE klein maakt, waardoor je geen waarde meer creëert.

Gebruik vertical slicing

Vertical slicing houdt in dat je alle lagen van de applicatie meeneemt en daarmee een waardevol item maakt. Als je alleen de database aanpast heeft de gebruiker hier nog niets aan, zolang deze geen scherm heeft en vice versa: als je een scherm bouwt, maar het niets doet, heb je er ook nog niet veel aan.

Refinement sessie

Wilt u weten hoe wij u kunnen helpen bij het kleiner maken van uw user stories, zodat u sneller waarde kunt leveren met een lager risico? Kijk dan eens naar  de refinement sessie of neem contact met ons op via onderstaand formulier.

Alex Roos, DevOps Consultant