User story's

Weet je nog?

Een user story is een korte beschrijving (story) van wat een gebruiker (user) wil. User story's dwingen je om te denken vanuit de gebruiker.

Een user story beschrijft vanuit de gebruiker, wat hij of zij op de website of app kan doen. Een user story is altijd in de volgende vorm:

Als <rol/ gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>.

Het eerste deel van deze zin beschrijft de rol. Een interactief product kan meerdere gebruikersgroepen hebben. Denk bijvoorbeeld aan de verschillende doelgroepen, de beheerder van de site, enz.. Je maakt voor alle rollen aparte user story's.

Het tweede deel van de zin bestaat uit wat de gebruiker wil doen. Dit maak je zo concreet mogelijk bijvoorbeeld: Als donor wil ik mij aanmelden voor de nieuwsbrief.  

Het laatste deel van de zin beschrijft het resultaat of het doel. Als donor (=rol) wil ik mij aanmelden voor de nieuwsbrief (=functie of actie) zodat ik op de hoogte blijf van de projecten die uitgevoerd worden (=doel).

Voorbeelden van user story's:

• Als boekkoper wil ik de klantbeoordelingen van een boek lezen zodat ik beter kan beslissen of ik het boek wil kopen.
• Als een geregistreerde gebruiker, wil ik een nieuw wachtwoord kunnen aanvragen zodat ik weer toegang kan krijgen als ik mijn wachtwoord vergeten ben.
• Als marketingmanager wil ik de resultaten van oude advertentiecampagnes kunnen zien zodat ik kan besluiten welke campagnes ik wil herhalen.
• Als student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb behaald.
• Als redacteur kan ik een blogartikel schrijven, zodat ik mijn verhaal met anderen kan delen.

Epics

De laatste story is eigenlijk een epic. Meestal beschrijft een epic een afgebakende taak van de gebruiker. Een epic is een omvangrijke user story die nog moet worden uitgesplitst in een set kleinere user story's.

Zo kun je de laatste epic splitsen in de volgende story's:

• Als redacteur kan ik mijn blog opmaken, zodat ik mijn verhaal aantrekkelijk kan presenteren.
• Als redacteur kan ik mijn blog tussendoor opslaan, zodat ik later verder kan werken.
• Als redacteur kan ik foto’s uploaden, zodat ik mijn verhaal met beeldmateriaal kan ondersteunen.

Alle user story's samen beschrijven de functionaliteit van een interactief product. Een eenvoudig project bestaat uit ongeveer 50 story's. Bij een complex project kan dit oplopen tot 500 of zelfs meer. Tijdens het hele ontwikkelproces van het product kunnen er story's bijkomen of story's veranderen.

Een voorbeeld van een complete lijst met user story's vind je op de site www.mountaingoatsoftware.com

INVEST

Een user story is goed wanneer het INVEST is. INVEST staat voor:

• Independent: zoveel mogelijk onafhankelijk van andere story’s
• Negotiable: bespreekbaar. Een story is geen wet, maar een behoefte van een user.
• Valuable: waardevol voor users of klant
• Estimable: Iedereen snapt wat er met de story bedoeld wordt, wat de story omvat
• Small: het kan gemaakt worden binnen een sprint
• Testable:  je kunt testen of er aan de story voldaan is

Tips voor het schrijven van user story's

Tip 1: User Come First

Een user story beschrijft hoe een klant of gebruiker verwacht van het product. Het is altijd geschreven vanuit het perspectief van de gebruiker.

Als je niet weet wie de gebruikers zijn en je weet niet met welk doel ze het product willen gebruiken, dan kun je geen user story's schrijven. Om te voorkomen dat je een product maakt waar niemand gebruik van maakt, begint elk project met gebruikersonderzoek.

Tip 2: Schrijf user story's nooit alleen

Een user story is een communicatie tool. User story's ontwikkel je met het hele projectteam en met de opdrachtgever. Discussieer over de story's. Je maakt dan gebruik van de creativiteit en de kennis van het team. Hierdoor krijg je betere user story's.

Tip 3: Houd story's eenvoudige en beknopt

Schrijf user story's zodat ze gemakkelijk te begrijpen zijn. Houd ze eenvoudig en beknopt. Vermijd verwarrende en dubbelzinnige termen. De volgende user story roept veel vragen op:

Als klant wil ik productspecificaties zien van het product dat ik ga bestellen zodat ik weet of het product wel goed genoeg is en of de specificaties wel goed genoeg zijn.

Tip 4: Begin met Epics

Wanneer je begint met epics dan kun je de functionaliteit van het product schetsen, zonder je te verdiepen in de details. Het maakt het gesprek over de user story's makkelijker. Je hoeft in het begin ook niet de strakke vorm voor user story's te gebruiken.

Breek daarna de epics in kleinere, gedetailleerde story's tot ze klaar zijn: helder, haalbaar en toetsbaar. Alle teamleden en de opdrachtgever moeten snappen wat er onder de story verstaan wordt.

Tip 5: Gebruik post-its of andere papieren kaartjes

Het werken op papier heeft een aantal voordelen:

• Papieren kaartjes zijn goedkoop en gemakkelijk te gebruiken.
• Ze bevorderen de samenwerking. Iedereen kan een kaart nemen en een idee opschrijven.
• Kaarten kunnen gemakkelijk worden gegroepeerd op de tafel of de muur. Dit geeft een goed overzicht.
• Je kunt een aparte kleur gebruiken voor de post-its per type gebruiker / doelgroep. Zo maak je bijvoorbeeld direct goed onderscheid tussen de story's voor de websitebeheerder en de bezoeker.

Zelfs als je een online systeem gebruikt, is het de moeite waard om post-its te gebruiken om nieuwe verhalen te schrijven. Wanneer je de belangrijkste woorden op een kaartje onderstreept, verhoog je de leesbaarheid. Kies een groter formaat post-it dan het standaard vierkante blokje. Je hebt dan meer ruimte voor de tekst en je kunt makkelijk onderscheid maken tussen de post-its met de taken die horen bij de story.

Tip 6: Houd user story's zichtbaar en toegankelijk

User story's zijn er om te communiceren over het product. Ze kunnen tijdens het project nog aangevuld of veranderd worden. Dit werkt beter wanneer ze zichtbaar zijn op bijvoorbeeld een scrumboard.

Voor- en nadelen van user story's

De voordelen van user story's:

• User story's zijn korte beschrijvingen van het product dat je gaat maken.
• User story's dwingen je om te denken vanuit de gebruiker.
• User story's zorgen ervoor dat je makkelijker communiceert in het ontwikkelteam en met de opdrachtgever.
• User story's worden gebruikt bij de projectplanning. Ze zijn zo geschreven dat van elke story een schatting kan worden gemaakt van de moeilijkheidsgraad en de benodigde ontwikkelingstijd
• User story's maken het mogelijk om het project op te delen in kleinere delen. Je kunt het project per story gaan uitwerken of bij een groot project de user story's verdelen over verschillende projectgroepen.

User story's zijn niet erg geschikt om de technische vereisten te beschrijven, omdat ze het product vanuit de gebruiker beschrijven. De gebruiker maakt het niet uit in of een product ontwikkeld is met Wordpress als het maar werkt. Als je de technische eisen moet beschrijven gebruik je andere tools.

Oefening 3

Lees de volgende epic:

Als bedienend personeel wil ik makkelijk de totaalprijs van de bestelling weten zodat ik snel kan afrekenen met de gasten.

Hierbij gelden de volgende prijzen en items:

1. Verdeel de epic in kleine story's en maak stap voor stap een prototype. Bewaar elke stap.
2. Het eindresultaat is een overzicht met alle artikelen per tafel met tafelnummer, aantal arikelen, naam artikel, totaal prijs zonder btw, totaal met btw en eventueel korting

MoSCoW

Niet alle user story's worden altijd uitgevoerd. Of ze worden uitgevoerd is afhankelijk van:

• het budget van de opdrachtgever
• het belang van de story

Om aan te geven hoe belangrijk een story is voor het behalen van het doel, gebruik je de MoSCow-methode.

De letters M, S,C, W in MoSCoW staan voor

• M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
• S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
• C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
• W - won't haves: deze eisen zullen in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn.

Van die laatste wordt vaak gedacht dat die voor "Would Have"staat, een soort "Nice to have". Dat is echt niet het geval, de "leuk om te hebben" categorie is al "Could Have"; de requirements waar we best zonder kunnen, maar als er tijd over is, is het een prettige toevoeging. Onderwerpen in de categorie Will not have worden gewoon niet gerealiseerd. Althans, en dat is het tweede misverstand, niet in deze fase.

Net als het schrijven van de user story's, gebeurt het toepassen van MoSCow in overleg met het hele team en met de opdrachtgever. de belangen van de gebruiker moet hierbij ook centraal staan.

Inventarisatie

User story's worden gebruikt binnen scrum als een manier om de eisen (requirements) te beschrijven. Scrum is een werkmethode. In het volgende hoofdstuk wordt scrum verder uitgelegd.

Vanuit user story's kun je een opsomming maken van wat er op de site moet komen. Dit noem je de inventarisatie.

Bij de inventarisatie maak je per user story een lijst met alle gewenste functionaliteiten en informatie (zowel input als output).

Als voorbeeld de user story: 'Als vmbo-leerling wil ik een overzicht van alle opleidingen van het Mediacollege zodat ik in één keer kan zien welke opleidingen aangeboden worden.'

Mogelijke inventarisatie:

• overzicht met alle opleidingen met per opleiding:
  • naam opleiding
  • foto opleiding
  • type opleiding (bol/ bbl)
  • duur opleiding
  • niveau opleiding
  • toelatingseisen
  • kwalificatiedossier
  • koppeling naar beschrijving opleiding

Nog een voorbeeld:

User story:
Als een geregistreerde gebruiker, wil ik een nieuw wachtwoord kunnen aanvragen zodat ik weer toegang kan krijgen als ik mijn wachtwoord vergeten ben.

Inventarisatie:

• link: wachtwoord vergeten?
• formulier met:
  • uitleg te nemen acties
  • invoerveld gebruikersnaam
  • invoerveld mailadres
  • verzendknop
• controle op invoer
• applicatie met de volgende functies:
  • genereren nieuw wachtwoord
  • versturen mail met:
    • uitleg reden mail
    • nieuw wachtwoord
    • link naar inlogpagina van site

Wanneer je wilt dat de gebruiker het automatisch gegenereerde wachtwoord om kan zetten naar een eigen wachtwoord, dan wordt de inventarisatie nog langer.

Bij scrum maak je de inventarisatie van een user story pas in de sprint waarin aan de story gewerkt wordt.