Tagcloud

Story decompositie – Deel 2

In deel 1 van deze blog is gesteld dat de juiste omvang van user stories en onderliggende taken enorm bijdraagt aan het slagen of falen van scrum. Ook is gesteld dat niet afgeronde sprints, slechte schattingen en slecht lopende Daily Scrums vaak symptomen zijn van werk dat niet de juiste omvang heeft. In het tweede en laatste deel van deze blog gaan we verder met een aantal tips om een user story op te delen.

Tip #6: Data entry methoden
Complexiteit zit soms in de user interface in plaats van de functionaliteit zelf. In zo’n geval is het raadzaam de user story te splitsen in de meest simpel mogelijke interface en eentje waarmee de wat geavanceerdere interface wordt gerealiseerd.

Laten we als voorbeeld een kijken naar de volgende user story “Als verkoopmanager wil voor een gegeven periode een 3D taartdiagram van de verkoopcijfers inzien”.

De meest simpele en toch functionele user story zou zijn om de gevraagde gegevens in een simpele tabel weer te geven. Middels een extra user story zouden we de complexere 3D representatie kunnen toevoegen. Merk op dat in alle beide gevallen de user story waarde oplevert voor de eindgebruiker. We vermijden dus het opknippen langs technische assen zoals programmeurs programmeurs gewend zijn. Merk op dat de user story nog steeds een potentiële valkuil heeft! De verkoopmanager komt namelijk met een oplossingsrichting, zonder het doel inzichtelijk te maken. Waarom is een taartdiagram überhaupt gewenst? Zeer waarschijnlijk omdat in een oogopslag een duidelijk beeld kan worden geschetst. Als dat de achterliggende behoefte is moeten we ons afvragen of er dan niet een geschiktere presentatievorm is dan een taartdiagram.

Tip #7: Uitstellen van NFR
Niet-functionele requirements kunnen soms wel een grotere inspanning vergen dan de functionaliteit zelf. Stel dat de opdrachtgever van de online boekenwinkel eist dat elke zoekresultaat binnen twee seconden wordt getoond. De kans is groot dat een programmeur begint met het leukste deel; de niet- functionele requirement. Het zou zo maar kunnen dat je dan aan het eind van de sprint met lege handen staat. Voldoen aan de snelheid eis bleek toch complexer dan gedacht. Het is verstandiger het bekende “just enough, just in time”-principe toe te passen en de focus eerst te leggen op het implementeren van het zoekresultaat zonder te voldoen aan de snelheid eis. Dit levert immers ook waarde aan de klant. Je leert van het tussenresultaat en je hebt dan een beter beeld hoeveel tijd je de volgende sprint moet reserveren om het werk onder de motorkap zodanig aan te passen dat ook aan de niet functionele eis kan worden voldaan. En bovendien het kan zijn dat de prioriteiten zo gewijzigd worden dat de NFR een lagere prioriteit krijgt.

De user story “Als online boekenkoper wil ik een boek zoeken op ISBN om snel een boek te kunnen aankopen”, kan aangevuld worden met de user story “Als online boekenkoper wil ik binnen twee seconden een boek kunnen vinden op basis van een ISBN-nummer”

Tip #8: CRUD
Het woord managen of beheren in een user story duidt er vaak op dat de story bestaat uit meerdere operaties. Dit is een natuurlijke manier om de user story te kunnen splitsen.

De user story “Als klant van een online boekenwinkel wil ik mijn accountprofiel beheren, zodat…”, kunnen we opdelen in:

  • “Als klant van een online boekenwinkel, wil ik mijn accountprofiel aanmaken, zodat…”
  • “Als klant van een online boekenwinkel, wil ik mijn accountprofiel wijzigen, zodat…”
  • “Als klant van een online boekenwinkel wil, ik mijn accountprofiel verwijderen, zodat…”
  • “Als klant van een online boekenwinkel, wil ik mijn accountprofiel bekijken, zodat…”

Tip # 9: user role of persona
User stories zijn het makkelijkst te identificeren rond een bepaald type gebruiker. Immers als we een bepaalde gebruiker voor ogen hebben kunnen we makkelijker nadenken wat hij of zijn nodig heeft en vooral waarom. In praktijk kan dit betekenen dat je dezelfde functionaliteit zou kunnen identificeren voor verschillende gebruikersrollen of personas. Zo zou je je een user story voor het aanschaffen van een boek voor zowel een zakelijke klant als een particuliere klant kunnen definiëren. Echter kunnen ze verschillende behoeften hebben. Daar komen we snel genoeg achter als we gebruikersrollen en personas centraal stellen in de analyse.
In de praktijk zie ik dat functionaliteit vaak geïdentificeerd wordt zónder specifiek na te denken voor wie het bedoeld is. In dat geval is het dus raadzaam om alsnog de user story op te splitsen als de betreffende functionaliteit van toepassing is op meerdere gebruikersrollen.

Tip #10: Spike
In sommige gevallen lukt het niet om een te grote user story functioneel kleiner te krijgen omdat er juist met betrekking tot de technische implementatie onduidelijkheid is. In dat geval kun je een ‘spike’ definiëren zodat er het een en ander uitgezocht kan worden. Met de uitkomst van een spike kunnen we alsnog de story implementeren of alsnog functioneel opbreken. Een spike zou echter de laatste optie moeten zijn. Je weet waarschijnlijk toch wel genoeg om iets te bouwen. Doe dat en je leert ervan.

Als het team van de online boekenzaak bijvoorbeeld nog geen ervaring heeft met het betalingsinterfaces, kunnen ze een spike definiëren. In een beperkte hoeveelheid tijd moet dan onderzocht worden hoe een creditcard betaling afgehandeld wordt. Belangrijk is dat een dergelijk onderzoek niet gaat zweven in tijd. Zorg dat de onderzoeksdoelen helder zijn om binnen de begrote tijd antwoorden te vinden op vragen. De uitkomst stelt het team in staat om uiteindelijk de oorspronkelijke user story alsnog te voltooien of op te delen.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution