Het denken in use cases en user stories is best lastig om mee te beginnen. De kans is groot dat de stakeholders binnen het project nieuw zijn met deze denkwijze. Het kan dan lastig zijn om deze stakeholders mee te krijgen in het format van use cases en user stories.

Houd het simpel, vertel een verhaal

Het is daarom goed om te beginnen met een gebruik verhaal (usage narrative in het Engels).  Het verhaal dat gaat over een gebruik van het systeem is een voorbeeld van de beoogde use case in operatie. Er wordt alleen ingegaan op een enkel scenario en een specifieke actor. In dit verhaal wordt gewerkt met een archetype van een gebruiker dat ook wel een persona wordt genoemd. Een persona is een karakterisering van een bepaalde actor. Het verhaal beschrijft een situatie van begin tot eind. Hier een voorbeeld van een fiets app die gebruikt wordt door Jelle.

Jelle wil een stuk gaan fietsen vandaag omdat het lekker weer is en vooral windstil. Zijn persoonlijke doel is dat hij 100km per week wil fietsen. Als hulpmiddel om zijn doelstelling te halen gebruikt hij een app voor de smartphone. Jelle start de app en kiest om een nieuwe rit te maken. De app zoekt naar een GPS signaal. Zodra het signaal gevonden is kiest Jelle om te beginnen met fietsen. De app detecteert beweging en start met het loggen van de rit. Na een uur of twee rijden is Jelle moe en is toe aan een stevige lunch. De app pauzeert automatisch omdat er geen beweging meer wordt gedetecteerd. Na de lunch rijdt Jelle verder en de app hervat weer automatisch. Eenmaal thuis aangekomen geeft Jelle aan op zijn app dat de rit voorbij is. De gegevens worden verwerkt en er zijn direct enkele statistieken beschikbaar zoals de totale afstand en de gemiddelde snelheid. Als er door de app een internetverbinding wordt gedetecteerd worden de gegevens gesynchroniseerd met de server.

Stakeholders die dergelijke verhalen schrijven worden beter in maken van een voorstelling van het systeem. Daarnaast is het een goede warming up om use cases te schrijven. Stakeholders die gezamenlijk verhalen schrijven krijgen ook nog eens een goed beeld van de doelstellingen. Het verhaal dekken lang niet alle requirements van het systeem maar helpen om de use cases en user stories te extraheren.

Concentratie op de waarde

Als het team bezig is met het gedrag van het systeem is het belangrijk om te concentreren op de waarde die het systeem biedt aan de gebruikers en stakeholders. Het is beter om te concentreren op hoe het systeem werkt dan op de hoeveelheid features en functies die het systeem moet bevatten. Use cases concentreren zich op hoe het systeem wordt gebruikt om een bepaalde doelstelling te behalen voor een bepaald type gebruiker. Use cases concentreren zich op meerdere manieren om een doelstelling te behalen, manieren die succesvol zijn en manieren die omgaan met mogelijke problemen die voor kunnen komen. Om het simpel te houden wordt eerst gezocht naar de meest eenvoudige manier om het doel te behalen. Dit wordt ook wel de ‘basic flow’ of nog mooier de ‘happy flow’ genoemd. Daarna worden de alternatieven in kaart gebracht om dezelfde doelstelling te behalen. Op de alternatieven wordt nog niet ingegaan. Vaak biedt een alternatieve manier niet meer waarde aan de gebruiker en stakeholders dan de simpelste manier.

Use case narrative

Hieronder is een voorbeeld weergegeven van een ‘use case narrative’. Deze methode wordt beschreven door Ivar Jacobson. Dergelijke modellen kunnen goed worden ingezet tijdens een concept- of specificatiefase van een project.

Naam use case: Loggen fietsrit

User story: Als een fietser wil ik mijn rit loggen zodat ik mijn persoonlijke doelstelling kan waarborgen

Basis flow

  1. Opstarten fiets app
  2. Zoeken GPS signaal
  3. Start loggen GPS coordinaten
  4. Stop loggen GPS coordinaten
  5. Weergeven statistieken
  6. Synchroniseren gegevens met server

Alternatieve flow

  • GPS signaal niet gevonden
  • Fietser beweegt niet voor een periode
  • Accu smartphone is op
  • Server is niet beschikbaar

Het is niet nodig om alle flows op papier te krijgen. Concentreer je op de basis flow. Ga na wat er mis kan gaan op iedere stap om de alternatieven te vinden. Het ontwikkelteam zal de basis flow als eerste implementeren omdat dit nodig is om de doelstellingen te behalen. Alle alternatieven zijn optioneel en kunnen dus ook op een later tijdstip op in een volgende release geïmplementeerd worden. Vraag jezelf ook steeds af of de alternatieven ook wel waarde bieden aan de stakeholders of gebruikers.