Waarom goede user stories soms toch tot de verkeerde oplossing leiden

De belofte van user stories. Binnen Agile werken zijn user stories een veelgebruikte manier om requirements vast te leggen. Ze bieden een eenvoudige structuur om behoeften te beschrijven vanuit het perspectief van de gebruiker: “Als … wil ik… zodat…”

Het idee hierachter is sterk. Door vanuit de gebruiker te denken, ontstaat meer focus op de waarde die een oplossing moet leveren. Toch blijkt dat in de praktijk niet altijd zo uit te pakken.

Wat er in de praktijk gebeurt

Hoewel user stories bedoeld zijn om behoeften vast te leggen, worden ze in de praktijk regelmatig gebruikt om oplossingen te beschrijven.

Bijvoorbeeld: “Als HR-manager wil ik een exportknop zodat ik verzuimgegevens kan downloaden”

Op het eerste gezicht lijkt dit een duidelijke user story. Er is een gebruiker, een wens en een doel. Toch roept deze story direct een aantal vragen op:

  • Wat probeert de gebruiker daadwerkelijk te bereiken?
  • Waarom is dit nodig?
  • Welk probleem probeert de gebruiker op te lossen?
  • Is een exportknop daadwerkelijk de oplossing voor het probleem?

De user story beschrijft hier niet zozeer de behoefte, maar een vooraf bedachte oplossing. Daarmee verschuift de aandacht van het begrijpen van het probleem naar het realiseren van functionaliteit.

Misschien wil de HR-manager de gegevens helemaal niet downloaden, maar wil hij periodiek rapporteren aan een externe partij. In dat geval zijn er mogelijk betere oplossingen denkbaar, zoals een geautomatiseerd rapport, een dashboard of een koppeling met een ander systeem. Wanneer die context ontbreekt, is het lastig te bepalen welke oplossing daadwerkelijk de meeste waarde toevoegt.

Van behoefte naar realisatie

User stories worden vaak opgesteld op basis van gesprekken met stakeholders, waarbij de nadruk al snel ligt op wat er gebouwd moet worden. Begrijpelijk, want stakeholders denken meestal in oplossingen voor problemen die zij ervaren. Daardoor krijgt de stap waarin het probleem wordt onderzocht en geanalyseerd soms minder aandacht. Het risico hiervan is dat oplossingen logisch lijken, maar uiteindelijk niet optimaal bijdragen aan de doelstelling.

Tegelijkertijd vervullen user stories een belangrijke rol binnen Agile teams. Ze vormen de basis voor de backlog, ondersteunen de sprintplanning en helpen bij het structureren van werkzaamheden.

Juist daarin schuilt echter een risico. De focus kan verschuiven naar het realiseren van user stories, terwijl het uiteindelijk zou moeten gaan om het realiseren van waarde. Een team kan immers succesvol alle stories opleveren, terwijl gebruikers nog steeds tegen dezelfde problemen aanlopen. Of er wordt functionaliteit ontwikkeld die nauwelijks wordt gebruikt omdat de werkelijke behoefte onvoldoende is onderzocht.

Het belang van analyse

Hier ligt een belangrijke rol voor de Business- en Informatie Analist.

De kracht van analyse zit niet in het beschrijven van een oplossing, maar in het begrijpen van het probleem. Door door te vragen naar doelen, knelpunten, processen en achterliggende behoeften ontstaat inzicht in wat er werkelijk speelt. Pas wanneer duidelijk is welk probleem moet worden opgelost en welke waarde daarmee wordt gecreëerd, kan worden bepaald welke oplossing het meest passend is.

User stories kunnen daarbij een waardevol hulpmiddel zijn. Niet als vervanging van analyse, maar als vertaling van een geanalyseerd probleem naar concrete ontwikkelwerkzaamheden. Ze voegen vooral waarde toe wanneer ze worden gebruikt:

  • Als hulpmiddel om het gesprek te structureren
  • Als vertaling van een onderliggende behoefte;
  • Als onderdeel van een bredere context van doelen, processen en stakeholders

In die situatie helpen user stories om richting te geven aan ontwikkeling zonder het zicht op de werkelijke behoefte te verliezen.

Conclusie

User stories zijn een bruikbaar instrument binnen Agile werken. De waarde ervan hangt echter sterk af van de manier waarop ze worden toegepast.

Wanneer user stories vooral oplossingen beschrijven, bestaat het risico dat teams functionaliteit realiseren zonder eerst voldoende stil te staan bij het onderliggende probleem. De aandacht verschuift dan van waardecreatie naar oplevering.

De vraag is daarom niet hoe goed een user story is geschreven, maar hoe goed het probleem erachter is begrepen. Want een perfecte user story levert nog geen waarde op als het verkeerde probleem wordt opgelost. Misschien zouden we daarom minder tijd moeten besteden aan het perfectioneren van user stories en meer tijd aan het begrijpen van de problemen die erachter schuilgaan.

Wil je meer over dit onderwerp weten? Neem dan contact op met Wendy Groven-Hogenboom, Business- en Informatie Analist bij Valid.