User story
Communicatie middel voor requirements.
Korte beschrijving van wat een gebruiker wil. Tegenovergesteld aan use cases zit dit meer op communicatieniveau dan specificatie.
Vertelt een verhaal tussen klant en analist. Moet makkelijk te verstaan zijn, zonder technisch jargon of voorkennis om formaat te begrijpen. Het doel is communicatie tussen IT en business.
Als een … wil ik … Zodat …
Bv: Als een bioscoopbezoeker wil ik mijn tickets laten sturen naar mijn gsm zodat ik niet hoef te wachten aan de kassa.
Waarom user stories
- Makkelijk te verstaan: geen technisch jargon, geen voorkennis nodig.
- Makkelijk te delen: communicatie tussen IT en business.
- Lage inspanning: snel op te stellen, moet niet perfect zijn.
- Makkelijk te plannen: stelt een werkitem voor.
User story invest regel
Een goede user story is:
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable
User story: independent
User stories moeten los van elkaar staan. Er kan bv. geen user story zijn die verwacht dat een andere user story al gedaan is.
User story: negotiable
User stories zijn geen contracten, ze beschrijven requirements zonder te specificeren.
Het is de start van een conversatie: de product owners bepalen de richting (verwachting; wat) en de developers bepalen hoe er te geraken (specificaties; hoe).
User stories kunnen wijzigen doorheen het project wanneer er meer kennis wordt vergaard. Sommige stories kunnen worden gesplit of zijn misschien onnodig.
User story: valuable
User story moet een business waarde bevatten zoals bv. meer opbrengsten, lagere kosten, klanten aantrekken, efficienter worden, …
User story: small
User stories moeten zodanig klein zijn dat kan worden ingeschat hoeveel tijd er in moet geinvesteerd worden, en kan realizeerbaar zijn in korte tijd (1 iteratie bv.).
User story niveaus
Er kunnen meerdere niveaus van stories bestaan om een verhaal te beschrijven:
- Epics (globale activiteiten, bv. ‘taken uitvoeren’)
- Stories (bv. ‘als lid wil ik een overzicht van taken’ of ‘als lid wil ik details zien van een taak’, …)
- Tasks (bv. ‘GET request op basis van lid’, ‘taken Business Logic’, ‘overzicht taken view’, ‘test schrijven’, … )
Epic
Groot stuk functionaliteit die business wil hebben en waarde oplevert. Wordt opgeleverd aan de hand van kleinere user stories, gespreid over meerdere iteraties.
Formaat van user stories moet niet gevolgd worden: mag (of moet) groot zijn.
Task
Onderverdeling van stories in uitvoerbare taken. Geschreven door het dev team voor het dev team en mag dus technisch zijn, hoeft geen directe business value te hebben, moet niet onafhankelijk zijn.
Input DevOps is belangrijk hierbij.
Customer journey
Ervaring van de klant van begin tot einde visualiseren. Inzicht krijgen in het gedrag van de klant.
Als doel om inzicht te krijgen in het gedrag van de klant.
Customer journey stappenplan
- Creeren van persona’s
- Identificeren van de verschillende fases, elk met hun doel en beschrijving van de activiteit
- Identifieer contactpunten tussen klant en bedrijf
- Beschrijf gevoel van de klant tijdens de actie
- Identificeer belangrijkste acties
- Vind ideeen voor verbetering / innovatie
Story map
Visuele oefening om shared understanding te creeren. Business en IT zijn hierbij beide aanwezig.
Brengt in kaart een narrative flow van algemene taken. Dit wordt typisch afgeleid uit de costumer journey en vormt de ‘backbone’. Bv. een product zoeken, product in winkelmandje steken, checkout, …
Onder backbone komen user stories die in meer detail gaan. Bv. producten kunnen sorteren, …
Wanneer alle activiteiten ontdekt zijn, kunnen prioriteiten worden gezet: welke items voor een eerste release? Welke voor latere releases? Vormt de start van een product backlog.
Van customer journey naar story map
- Na maken van customer journey, beslis wat te investigeren: welke punten verbeteren? Welke pijnpunten weghalen? Welke innovaties maken?
- Identificeer kansen en bedreigingen.
- Zet een hypothese op.
- Identificeer de nodige mensen om het te verwezenlijken.
MVP
Minimum viable product.
Beschrijft wat er nodig is om een ‘goed’ product te bekomen.
MoSCoW methode
- Mo (Must have): essentiele elementen die onmogelijk kunnen ontbreken.
- S (Should have): belangrijke elementen maar minder van essentieel belang.
- Co (Could have):leuke extraatjes als er tijd en geld is, nice-to-haves.
- W (Won’t have): elementen die geen waarde toevoegen.
