User Stories zijn het probleem, niet de oplossing!
Heb je het gevoel dat je team tijd verspilt aan het ontwikkelen van functies die de eindgebruiker uiteindelijk niet of te weinig gebruikt? Misschien maak je je zorgen dat je project achterloopt, omdat er tijd van het ontwikkelteam opgaat aan de verkeerde dingen? Of vraag je je af hoe je beter kunt inspelen op veranderingen in de markt en de behoeften van je gebruikers?
User Stories zijn het probleem, niet de oplossing!
En juist daarom zijn User Stories misschien wel de oplossing voor jou. Klinkt verwarrend? In dit blog leggen we het uit en vertellen we hoe je zelf met User Stories aan de slag kunt gaan.
Download hier een workshop template!
Wat zijn User Stories?
Een goede User Story is een korte, informele beschrijving van de gebruikers van een systeem, hun doel en welke waarde dit doel voor hen heeft. Deze Stories focussen op het ‘wie’, ‘wat’ en ‘waarom’ van een bepaalde functionaliteit, zónder een oplossing voor te stellen of te diep in technische details te duiken. Het perspectief van de eindgebruiker wordt centraal gezet.
De rol van User Stories in softwareontwikkeling (en testing)
Door het ‘wie’, ‘wat’ en ‘waarom’ te combineren in een beknopte verklaring, bieden User Stories een gestructureerde manier om de vereisten van de eindgebruiker te definiëren en te communiceren naar het ontwikkelteam. Zij gebruiken de User Story als uitgangspunt om het gewenste systeem te bouwen. Het team verdiept zich in de gebruiker en verplaatst zich in hun behoefte. Vervolgens doen ze waar zij het beste in zijn: de best mogelijke softwareoplossing bedenken en bouwen.
Hierdoor ontstaat software die beter aansluit bij de behoeften en verwachtingen van de gebruiker dan wanneer de gebruiker zelf met een oplossing was gekomen. Ga maar na: de gebruiker of stakeholder is expert in het formuleren van doelen en uitdagingen. De developer is op zijn beurt expert in softwareoplossingen. De User Story is het communicatiemiddel dat beide perspectieven samenbrengt. Dus, terugkomend op de stelling dat User Stories het probleem zijn en niet de oplossing:
User Stories zijn de beste beschrijving van het probleem of doel van een gebruiker en bevatten geen oplossing, waardoor een ontwikkelteam de beste oplossing kan maken.
Bovendien vormen User Stories de basis voor het testen van software. Door gebruiksscenario’s in de vorm van User Stories te definiëren, kunnen Testers beter begrijpen hoe de software zal worden gebruikt en effectiever testcases ontwikkelen. Dit vermindert risico’s en zorgt ervoor dat je later in het proces voor minder verrassingen komt te staan.
Voordelen van effectieve User Stories
Maar User Stories hebben meer voordelen:
- Ze bevorderen de transparantie en betrokkenheid gedurende het hele ontwikkelingsproces, wat het risico op miscommunicatie vermindert.
- Ze stimuleren iteratief ontwikkelen door de focus te leggen op kleine, behapbare stukjes functionaliteit, waardoor het team flexibeler kan inspelen op veranderende vereisten.
- Daarnaast betrekken User Stories minder technische stakeholders bij het proces. In moderne softwareprojecten wordt vaak gebruik gemaakt van complexe technische termen die zelfs binnen het team niet altijd begrepen worden. Dit kan het project verstoren en risico’s met zich meebrengen.
- User Stories vereenvoudigen de communicatie, waardoor elk teamlid kan bijdragen door simpelweg vanuit gebruikersperspectief te denken. Hierdoor kan het team samenwerken zonder technische taalbarrières, wat een positieve impact heeft op de dynamiek en effectiviteit.
Hoe maak je effectieve User Stories?
Het maken van effectieve User Stories vraagt zorgvuldige aandacht voor detail en een goed begrip van de behoeften van de eindgebruiker. Ook de manier waarop je User Stories schrijft, speelt een cruciale rol bij het ontwikkelen van succesvolle software. Een praktische tip is daarom het gebruik van een gestructureerde format:
“Als [gebruiker/rol], wil ik [doel], zodat [waardevolle reden]”
Door het gebruik van dit format wordt de essentie van de functionaliteit op een duidelijke en begrijpelijke manier vastgelegd. Deze heldere formulering helpt misverstanden en ambiguïteiten te vermijden, waardoor het ontwikkelteam en de belanghebbenden een gedeeld begrip krijgen van wat er moet worden gebouwd. Een eenvoudig voorbeeld van deze toepassing is de volgende:
Wie: Als klant die een bestelling heeft gedaan,
Wat: wil ik de status van mijn bestelling kunnen volgen,
Waarom: zodat ik weet wanneer ik de levering kan verwachten.
Beproefde hulpmiddelen om je User Stories nog beter te maken, zijn het toepassen van het SMART- (Specific, Measurable, Achievable, Realistic en Timely) en INVEST-principe (Independent, Negotiable, Valuable, Estimable, Small en Testable). Een aantal belangrijke elementen van SMART en INVEST zijn hierboven al eens benoemd.
Om deze algemene concepten praktisch toepasbaar te maken voor jouw project of team, is het essentieel om per User Story samen in gesprek te gaan en de ideale afstemming te vinden. Er is geen one-size-fits-all. Na verloop van tijd zul je merken dat jullie steeds beter worden in het vinden van de juiste balans tussen de principes bij het schrijven van User Stories voor jullie systeem en context. Met tot gevolg: doelmatige software en grip op efficiënte softwareontwikkeling.
Hoewel de tips hierboven een goed startpunt bieden, is het vaak verstandig om samen te werken met ervaren professionals om het proces verder te verfijnen en te optimaliseren voor jouw organisatie. Mocht je hier vragen over hebben: laat het ons dan weten! We komen dit graag verder toelichten.
Wil je meer weten over requirements engineering of kun je hulp gebruiken bij het opstellen van goede User Stories? Ik vertel je graag meer over onze Business Analisten!
Dekken User Stories altijd alles wat er te zeggen valt?
Een veelgehoorde beperking bij het gebruik van User Stories is dat ze niet in alle situaties toepasbaar zijn, of niet alle essentiële informatie dekken. Daarom moet je de User Stories aanvullen met andere manieren om informatie vast te leggen. Op die manier versterken de verschillende formats elkaar.
Allereerst is het aan te raden iedere User Story aan te vullen met duidelijke context, bij voorkeur tijdens een (refinement) sessie met het hele team. Door de context toe te lichten, krijgen alle teamleden een gedeeld begrip van de beoogde functionaliteit en de behoeften van de eindgebruiker. Illustraties of (stroom)modellen kunnen deze context nog verder versterken.
Daarnaast hoeft niet ieder soort taak in het User Story format te worden vastgelegd. Wanneer de focus niet op direct op de eindgebruiker ligt, kunnen alternatieven zoals Problem Stories, Improvement Stories geschikter zijn. Uiteindelijk gebruik je User Stories en andere templates vooral als nuttige hulpmiddelen om tot succesvolle software te komen en zijn ze geen doel op zichzelf.
User Stories: een praktijkvoorbeeld
Hoewel User Stories vaak geassocieerd worden met Agile ontwikkelingsmethodologieën, kunnen ze ook binnen een waterval- of projectaanpak waardevol zijn. Door het gebruik van User Stories binnen waterval- en projectomgevingen kunnen ook hier ontwikkelingsteams de focus leggen op de behoeften van de eindgebruiker gedurende het hele project. Dit vermindert het risico op het ontwikkelen van onnodige functies en wordt tijd effectief besteed, wat het projectsucces vergroot.
Requirements opstellen
Een mooi voorbeeld van het succes van de User Story komt toevallig uit zo’n projectomgeving. Bij een grote overheidsorganisatie mochten wij helpen met het opstellen van requirements voor de herbouw van een verouderd systeem. De opdracht was simpel: ‘het nieuwe systeem moet mínstens kunnen wat het oude systeem kan’.
Het verouderde systeem verwerkte meetgegevens en koppelde deze aan een ruimtelijke 2D weergave van het object. Gebruikers konden deze objecten intekenen om vervolgens de meetgegevens te bekijken en de kwaliteit van de objecten over de tijd te monitoren.
User story mapping
Normaal gesproken zouden de bestaande systeemeisen simpelweg worden hergebruikt als blauwdruk voor het nieuwe systeem. Echter was dit project al meerdere keren vastgelopen. Om het project een nieuw leven in te blazen, introduceerden we de (voor deze situatie) onconventionele aanpak van User Story Mapping sessies: Sessies waarbij alle betrokkenen vanuit hun perspectief op geeltjes schrijven wat zij nodig hebben van het nieuwe systeem.
Eén User Story, waarin gebruikers vroegen om – net als in het oude systeem – ook in het nieuwe systeem de objecten te kunnen intekenen, bracht een cruciale verandering teweeg. Om aan deze wens te voldoen zou het nieuwe systeem – net als het oude systeem – een dure, complexe en gebruiksintensieve module moeten krijgen om 2D objecten te tekenen. De eindgebruikers hadden dus eigenlijk een oplossing beschreven.
Een oplossing voor welk probleem? Na verdiepende vragen ontdekten we dat het achterliggende doel van de eindgebruikers was om de achteruitgang van de objecten visueel te kunnen zien, zodat ze konden zien waar belangrijke stukken achteruitgingen en ze onderhoudsadvies konden uitbrengen.
Essentieel verschil
Waarom is dit verschil essentieel? Het nieuwe systeem kon hierdoor de dure, complexe module voor het intekenen achterwege laten. In plaats daarvan kon een bestaande database met de objecten aan het systeem worden gekoppeld, waardoor gebruikers de meetresultaten in 2D konden zien en hun echte doel werd bereikt.
Dit voorbeeld illustreert opnieuw het punt dat we eerder in de introductie hebben benoemd: User Stories zijn het probleem, niet de oplossing. Deze User Story maakte een wezenlijk verschil voor het succes van het project, omdat het iedereen in staat stelde het perspectief en de behoeften van de gebruiker echt te begrijpen en zo ruimte te laten voor de optimale oplossing.
