User stories: sterke basis, happy gebruikers
5,00/5Goede customer experience is tegenwoordig hartstikke belangrijk. Om de user experience zo veel mogelijk te optimaliseren zijn er verschillende mogelijkheden. User stories kunnen je hierbij helpen. Nee we hebben het hier niet over Instagram, Facebook of zelfs LinkedIn stories maar over user stories? Nog nooit van gehoord? Geen probleem, hier lees je een inleiding over de mogelijkheden met user stories en wat een user story precies voor je kan doen. We doen alles voor een goede user experience toch?
De definitie van user stories
Voor we bespreken hoe je user stories kunt gebruiken is het misschien makkelijk als we even uitleggen wat een user story precies is en wat je ermee kunt. Een user story is een hulpmiddel dat wordt gebruikt bij de ontwikkeling van Agile software om een beschrijving van een functie vast te leggen vanuit het perspectief van de eindgebruiker (de user). Een user story beschrijft het type gebruiker, wat ze precies willen en ook waarom. User stories helpen om een vereenvoudigde omschrijving van een vereiste (requirement) te maken.
Een requirement is een andere term die we er gelijk maar even uit zullen pikken. We kunnen het namelijk niet hebben over user stories zonder dat we ook requirements bespreken,. Requirements moet je zien als eisen die gesteld worden aan het gedrag of de kwaliteit van een systeem zodanig dat het voorziet in de behoeften van de belanghebbenden .
De overeenkomst is dat beide termen dus feitelijk de wens beschrijven van een gebruiker en legt het uit waar het aan moet voldoen.
Als we het over user stories en requirements hebben is er nog een term die we je moeten toelichten. Dat is het woord Epic. Een epic moet je zien als een flinke workload dat meer sprints in beslag neemt. Sprints kun je zien als afgesproken periodes waar een of meerdere (kleine) projecten of aanpassingen gedaan. Zo kan een sprint bijvoorbeeld een week, twee weken of meerdere maanden duren. Het is een periode waarin meerdere projecten worden afgerond. Als een project meerde sprints nodig heeft kun je dit zien als een Epic.
Het klinkt misschien nog wat ver van je bed en misschien heb je nog nooit van Agile software development gehoord. Laten we die term er dan ook maar eens bijpakken. Software ontwikkeling staat al jaren bekend als een tijdrovend proces. Het gaat nooit snel genoeg en er zijn allerlei processen om je aan vast te houden. Een groep developers bedacht dat deze tijdrovende processen wel eens anders moesten en kwamen met Agile software development. Dat houdt in dat de software ontwikkeling met name vlug en flexibel moest worden.
Een professionele werkwijze maar zonder honderden documenten en bureaucratie. Agile software staat voor flexibeler, sneller en dus ook klantvriendelijker werken. Dit komt met name omdat de klant meer aandacht krijgt dan de gebruikte processen en tools. Je ziet het al, het komt de user experience opnieuw ten goede.
Bron: Pexels
Waar moet een user story aan voldoen?
Inmiddels ben je er al wel achter dat er dus niet al te lichtzinnig gedacht kan worden over user stories. Er zijn ook een aantal kwaliteitseisen die worden gesteld worden aan user stories. Voor we een aantal voorbeelden geven van user stories, bekijken we eerst wat deze eisen zijn. Er is zelfs gedacht om de kwaliteitseisen van een user story een handige naam of ezelsbruggetje te geven. Dit is INVEST.
- Independent: dit staat voor een functionaliteit die onafhankelijk ontwikkeld kan worden van andere functies
- Negotiable: de user experience moet een ambitie uitspreken om een doel te behalen en hier moet over gediscussieerd kunnen worden.
- Valuable: De user story moet een bepaalde waarde opleveren voor een van de stakeholders.
- Estimatable: De omvang en complexiteit moet in te schatten zijn door het core team
- Small: De ontwikkeling van de user story moet binnen een sprint gerealiseerd kunnen worden
- Testable: Een user story moet ook beschrijven hoe deze getest moet worden na de realisatie.
User stories helpen dus bij agile development. Toch kan een user story soms net te weinig details bevatten en daarom zijn requirements dan weer een goede aanvulling. De product owner kan hier zijn wensen en vereisten doorgeven en zal vaak net iets meer in detail denken zodat het concept ontwerp wat vollediger wordt uitgewerkt. Omdat user stories en requirements samen een volledig beeld geven van wat de opdrachtgever maar ook de eindgebruiker verwachten, geven beiden veel waarde aan het development team.
Hoe maak je een user stories?
Een user story is onderdeel van een agile scrum. Zo’n scrum is eigenlijk een set van meetings, tools en rollen die een team gestructureerd laat werken. Onder een agile scrum valt dus een user story maar ook een requirement. Het verschil tussen Agile en Agile Scrum is dat Agile een continue proces is, zie het als het grotere geheel. Scrum levert steeds in elke sprint een proces of stuk software af (kortere etappes).
Een user story begint vrij gemakkelijk. Er is eigenlijk maar een zin nodig om je user story te maken. Die zijn luidt als volgt:
“ Als gebruiker wil ik <…> zodat <…>.
De product owner zal de user stories bedenken maar het kan ook voorkomen dat de verantwoordelijke advies inwint bij de developers, UX-designer of iemand anders binnen het development team. Bij het maken van user stories is het belangrijk om zo concreet mogelijk te zijn.
“Als gebruiker wil ik het menu aanpassen zodat het menu aangepast is.” heeft geen enkele waarde.
“Als gebruiker wil ik het menu indelen met de meest populaire pagina’s zodat ik makkelijker kan navigeren.” is een concreet voorbeeld.
Nu je weet wat user stories, requirements, sprints en stories zijn is het tijd om je te laten zien hoe je al deze aspecten van agile development laat samensmelten
Hoe laat je epics, requirements en user stories samenkomen?
Een user story is een belangrijk fixatiepunt voor design. Requirements helpen het development team bij het vaststellen van overige vereisten. Zodra de requirements bekend zijn wordt er gekeken naar welk werk er gedaan moet worden om de veranderingen of nieuwe projecten uit te voeren. Het team of de product owner legt in een epic vast wat het werk is om de klantwaarde te realiseren en zorgt bovendien voor voldoende controlepunten.
Vervolgens wordt de epic ingedeeld in verschillende sprints. Dit zijn meerdere projecten die binnen de epic worden uitgevoerd. Bij een user story kunnen er overigens meer afdelingen inspraak hebben dan enkel IT. Marketing maar ook customer care kan product owner zijn van een user story,
Bron: Pexels
Acceptatiecriteria
Waar moet een functionaliteit aan voldoen om te worden geaccepteerd. Deze acceptatiecriteria schetsen feitelijk de kaders voor de te maken oplossingen. Er zijn verschillende oplossingen mogelijk. Het is handig om de acceptatiecriteria duidelijk vast te leggen en te markeren zodat direct bij de development hier rekening mee gehouden kan worden. Denk bovendien niet te makkelijk over de acceptatiecriteria. Juist als een team nog niet zo lang met elkaar werkt is het belangrijk om de criteria goed uit te schrijven zodat er (zeker qua design) geen misverstanden kunnen ontstaan.
Definition of Ready versus Definition of Done
Er zijn verschillende fases van een user story. Met DoR oftewel Definition of Ready wordt er door het team gekeken of een user story klaar is om aan een sprint te worden opgenomen. Vaak wordt de Definition of Ready status toegekend als er een vrijwel volledig gespecificeerd ontwerp is. Bij teams die meer op elkaar zijn ingewerkt kan een DoR al worden toegekend bij een schets van de user story. Het design wordt zo dan verder uitgewerkt gedurende een sprint.
De Definition of Done is de volgende stap. De DoD bepaalt of de software klaar is om “live” te gaan. Na goed testen en de controle of aan alle acceptatiecriteria wordt voldaan kan de status Definition of Done bereikt worden en wordt dus feitelijk de sprint of epic afgesloten en groen licht gegeven.
Hoe te beginnen?
Na alle informatie over user stories, requirements, sprints, acceptatiecriteria en epics heb je al genoeg kennis om met je agile project te starten. Laten we je in een paar stappen eens uitleggen hoe je kunt starten. Dit kan als met post-its aan je muur of whiteboard.
- Bekijk goed je situatie en kies samen met je team of je twee goede voorbeelden van user stories of epics kunt vinden. Schrijf dit op een blad of post-it en hang aan je muur.
- Bedenk wat de requirements van je project kunnen zijn en hang dit onder de stories.
- Welke stappen zijn er nodig om je user story tot leven te brengen? Maak een checklist.
- Spreek af hoe lang de sprint of epic zal duren. Wees realistisch, pak liever een paar dagen extra dan te weinig.
- Check continue hoe het verloop van je agile project verloopt. Zijn er aanpassingen nodig, hoe beleeft elk teamlid het project, is er ergens extra aandacht nodig?
- Streep af welke (mini)projecten of requirements zijn voldaan.
- Test de uitkomst, zet je project op DoR en ga live als alle resultaten goed zijn.
Conclusie
Een user story bestaat uit de beschrijvingen van het perspectief van de eindgebruiker net als requirements. Door user stories als startpunt aan te houden bij de ontwikkeling van je project wordt de user experience geoptimaliseerd. De combinatie van user stories en requirements worden in een sprint of epic geplaatst om zo het agile project in goede banen te leiden. Developers maar ook designers hechten een hoop waarde aan user stories omdat door de vele processen het oogpunt van de klant nogal eens vergeten wordt. User stories helpen dus enorm bij het bereiken van een goede customer experience.
