skip to Main Content
User Story’s Splitsen Met Behoud Van Waarde

User Story’s splitsen met behoud van waarde

“Jan, je hebt het misschien al gehoord maar het team dreigt uit het werk te lopen. Heb je die User Story inmiddels Ready?”. Als business analist in een programma met 4 scrumteams is het niet altijd even makkelijk om met je specificaties voor te blijven op de teams. De User Story waaraan gerefereerd werd ging om het verwerken van een bericht met als gevolg twee mogelijke mutaties in de database. De ene mutatie, het simpele toevoegen van een record in de database, was me duidelijk maar de andere, een ingewikkelde extrapolatie op bestaande gegevens, had ik nog niet voldoende scherp gespecificeerd en moest nog verder worden besproken met de gebruiker.

“Nee, zover ben ik nog niet” was mijn antwoord aan de Scrum Master, “misschien kunnen we samen kijken wat jullie al wel op kunnen pakken?”.

De meest voor de hand liggende oplossing in dit geval is om de User Story te splitsen zodat het team alvast kan starten met het deel dat wel duidelijk is. Dat gaf mij de tijd om nader overleg te voeren over het onduidelijke deel. De Scrum Master was blij met die mogelijkheid en stelde voor om dan voor de komende sprint te beginnen met de component die het bericht controleert, uitpakt en klaarzet.

Dat leek me om twee redenen geen goed idee:

  1. In een agile omgeving is het namelijk de bedoeling dat bij iedere iteratie het systeem wordt uitgebreid met waarde voor de business. Wat precies die waarde is daarover kunnen de verschillende stakeholders van mening verschillen maar een systeem dat enkel in staat is om een bericht uit te pakken en vervolgens niets doet met die informatie heeft voor de business geen waarde.
  2. De gebruikers kunnen tijdens de demonstratie aan het eind van de sprint geen feedback geven op de gekozen oplossing en dus krijgt het team niet te horen of de juiste weg is ingeslagen. De kans is dan aanwezig dat er in een later stadium, als de gebruikers het eindresultaat hebben beoordeeld, werk opnieuw moet worden gedaan of dat zelfs blijkt dat er werk voor niets is geweest.

Het opdelen van user story’s

Het is dus handig, wanneer je een user story opdeelt, te kijken naar het doel van de user story en dat doel vervolgens op te splitsen in subdoelen die elk een deel van het einddoel invullen. Het voordeel voor zowel team als eindgebruiker is dan dat er met iedere user story waarde wordt geleverd waar de gebruikers feedback op kunnen geven.

Vaak wordt een user story echter opgedeeld in functionele componenten zoals “controleren bericht”, “bepalen mutaties” en “uitvoeren mutatie”. Dat blijkt in de praktijk minder goed uit te pakken; pas als alle functionele componenten zijn gerealiseerd kan een gebruiker aangeven of de functionaliteit in zijn geheel voldoet of niet.

In overleg met de Product Owner heb ik de user story gesplitst en drie nieuwe, elk met een resultaat waar de business bij gebaat is:

  1. Het vastleggen van de ontvangen gegevens in een tabel die via de userinterface is te raadplegen;
  2. Het aanpassen van bestaande grafieken op basis van de ontvangen gegevens;
  3. Het extrapoleren op de bestaande gegevens.

Het team kon in de volgende sprint aan de slag met de eerste user story en ook de tweede was klaar om opgepakt te worden. Ik had de tijd om het complexe deel, de ingewikkelde extrapolatie, verder uit te werken.

Na een paar weken stond ik met de Product Owner bij de koffiemachine. “Jan, die demo ging goed, fijn dat we aan het einde van een sprint een nieuw stuk kunnen laten zien. De gebruikers zijn nu veel meer betrokken en krijgen vertrouwen in het nieuwe systeem.”

Let dus bij het splitsen op doelen met waarde en zoek niet meteen naar functionele componenten!

Back To Top
X