Expert in requirements

User stories: mijn 3 gouden regels

What’s your story

Benut jij de user stories techniek al ten volle? Ik zie te vaak dat men user stories gebruikt als traditionele requirements zinnen. Dat is jammer, want in agile en hybride trajecten is er zoveel meer uit te halen.

Pas de volgende 3 gouden user story regels toe om de voordelen van de techniek ten volle te benutten.

1. Beschouw user stories en requirements als aannames

Het is niet reëel om te verwachten dat de product owner en andere stakeholders bij voorbaat weten wat hun requirements (tot in detail) zijn. Om zich daar een goed beeld van te vormen, hebben ze werkende software nodig. Pas dan gaat het systeem voor ze leven. Met een agile aanpak kun je inspelen op dit gegeven.

Beschouw user stories en requirements als aannames die nog getoetst moeten worden. En toets ze door de ontwikkelde software voor te leggen aan gebruikers. Vraag ze, zo vaak als praktisch mogelijk, feedback op de ontwikkelde software en stimuleer voortschrijdend inzicht.

Bouw het systeem en de requirements proefondervindelijk op. Je hoeft niet meteen de juiste requirements voor het uiteindelijke systeem boven water te halen. Maak er een ontdekkingstocht naar het optimale systeem van.

2. Houd het aantal user stories beperkt

Muur met geeltjes

Een lange lijst kleine user stories die ooit nog geïmplementeerd moeten worden (als de inzichten in de tussentijd niet gewijzigd zijn), maakt de product backlog onoverzichtelijk, bezorgt je onnodig werk en schept verkeerde verwachtingen. Splits daarom grote user stories pas op tegen de tijd dat ze gerealiseerd gaan worden.

Zet uitsluitend de kleine user stories op de product backlog die het ontwikkelteam in de komende 2 à 3 sprints gaat oppakken. Dat geldt ook voor de requirements en user stories die ontstaan naar aanleiding van feedback en voortschrijdend inzicht (zie 1e gouden tip). Alle kleine user stories die niet op korte termijn geïmplementeerd kunnen worden gooi je weg. Dat voelt in het begin misschien ongemakkelijk, maar zal je van een hoop waste (om in Lean termen te spreken) verlossen.

‘Vergeten we die user stories c.q. requirements dan niet?’, vragen analisten en product owners me vaak. Nee, als hij belangrijk genoeg is en over een paar maanden nog steeds actueel is, komt hij ongetwijfeld opnieuw op tafel.

3. Stimuleer het ontwikkelteam om vragen te stellen

Actieve participatie van het ontwikkelteam is cruciaal voor het succes van een agile traject. Dat is een hele omslag wanneer de ontwikkelaars gewend zijn om alle requirements compleet gespecificeerd te krijgen en een ‘u vraagt wij draaien’-houding hebben. Toch heeft het teveel voordelen om het te laten lopen. Dit zijn de voornaamste voordelen:

  • Je krijgt een systeem met veel meer businesswaarde, als je gebruik maakt van de expertise en creativiteit van het hele multidisciplinaire team. Als het team begrijpt wat de business met het systeem wil bereiken, kunnen ze meedenken en oplossingen en ideeën aandragen. Zij kennen de (on)mogelijkheden van de techniek als geen ander en komen vaak met ideeën waar een ander niet op komt.
  • Je hoeft de requirements niet uitgebreid te beschrijven. Het voltallige ontwikkelteam heeft immers geholpen met het scherpstellen van de user stories. Dit bespaart je veel tijd én minimaliseert de kans op interpretatieverschillen. Zeker wanneer de user stories just in time worden gedetailleerd, heeft het team genoeg aan het vastleggen van enkele geheugensteunen (precies zoals user stories bedoeld zijn).
  • Je hoeft je niet af te vragen hoe ver je de user stories moet detailleren. De ontwikkelaars blijven namelijk vragen stellen totdat ze genoeg informatie hebben om de user story op te nemen in een sprint.

Hoe je ontwikkelaars met een ‘u vraagt wij draaien’-houding zo ver krijgt dat ze vragen gaan stellen.

Meestal is het niet voldoende om dit type ontwikkelaars uit te leggen waarom hun actieve bijdrage in de refinement meetings zo belangrijk is. Hoewel zeer nuttig is een agile of Scrum training gewoonlijk ook onvoldoende om hun houding bij te stellen. Met de volgende praktische tips kun je ze ongemerkt toch een heel stuk in de goede richting duwen.

Tip 1. Werk de user stories niet volledig uit

Geef ze bewust geen compleet uitgewerkte requirementsspecificaties. Dan moeten ze wel vragen stellen om aan de ontbrekende informatie te komen.

Tip 2. Maak het stellen van vragen zeer laagdrempelig

Zorg dat je (of de product owner of key user) vaak bij hen op de kamer aanwezig bent. Vraag ze regelmatig of alles duidelijk is en of je ergens bij kunt helpen. Vraag ook of ze het op prijs stellen als je alvast naar de net gebouwde software kijkt om te checken of je alles duidelijk had overgebracht.

Tip 3. Start met planningpoker

De ontwikkelaars zijn de enige die een goede inschatting van de omvang van een user story kunnen maken. In het begin zal dat ook voor hen niet meevallen. Reken ze daar in geen geval op af. Maar maak er een leerproces van en bekijk samen hoe jullie het inschattingsproces kunnen verbeteren. De conclusie is bijna altijd dat de user stories niet helder genoeg waren. De oplossing die je dan aandraagt is dat je de requirements voortaan mondeling toelicht en de ontwikkelaars vragen laat stellen totdat ze genoeg weten (voor een 80% betrouwbare schatting).


In hoeverre pas jij deze gouden user story regels al toe?

Ik ben benieuwd naar je ervaringen met user stories en de problemen waar je eventueel tegenaan loopt. Wil je ze in het reactieveld hieronder delen? Dan kan ik mijn artikelen nog waardevoller voor je maken.

Succes met de requirements,

Nicole de Swart

PS Vond je dit artikel interessant? Deel het dan op Twitter, LinkedIn, Facebook of Google+ door op onderstaande knoppen te klikken.


Reacties (0)


Geef een reactie

Gratis preview Handboek Requirements

Cover ‘Handboek Requirements’

Lees alvast 5 hoofdstukken uit het compleet vernieuwde boek

Nicole de Swart

Nicole de Swart

Volg Nicole op:

Gratis video met tips voor user stories

Masterclass ‘Vervolmaken van je user stories’

Ontdek hoe je 5 door analisten veel gemaakte fouten omzeilt