wanneer je begint te duiken in Agile, is het eerste wat je opvalt hoe gebruikersgericht deze aanpak is. Het verschuift de focus van alleen coderen en ontwerpen naar het leveren van echte waarde aan uw eindgebruikers, stakeholders en het bedrijfsleven in het algemeen.
Agile User Stories zijn een essentieel onderdeel van deze ideologie waarmee u kunt bepalen welke voordelen uw product zal brengen aan uw doelgroep (en, uiteindelijk, hoe het zal uw KPI ‘ s en andere statistieken te stimuleren).,
We at Stormotion love Stories. Als Agile-gedreven Team gebruiken we ze actief om een beter inzicht te krijgen in de voordelen die de producten van onze klanten bieden aan hun eindgebruikers. Ze stimuleren ook samenwerking en creativiteit, en duwen ons naar niet-triviale ontwikkelingsoplossingen.,
vandaag gaan we onze kennis en ervaring op dit gebied delen om u te helpen uw verhaal-schrijven vaardigheden te verbeteren. Geniet ervan!
🤔 Wat is een gebruikersverhaal?
gebruikersverhalen zijn een van de kernelementen van de Agile-methodologie. Echter, ze zijn vaak door elkaar gehaald met software-eisen die niet waar is. Dus wat is een gebruikersverhaal?
User Story is een klein (eigenlijk het kleinste) stuk werk dat een waarde vertegenwoordigt voor een eindgebruiker en kan worden geleverd tijdens een sprint.,
het belangrijkste doel van dit element is om eindgebruikers in het centrum van gesprek te plaatsen en productfunctionaliteit vanuit hun perspectief vast te leggen. Zo krijgen ontwikkelaars een beter begrip van wat, voor wie en waarom ze bouwen.,
geweldige gebruikersverhalen passen altijd bij de INVEST set criteria door Bill Wake:
- onafhankelijk – ze kunnen worden ontwikkeld in elke volgorde en wijzigingen aan een gebruiker verhaal hebben geen invloed op de anderen.
- onderhandelbaar-het is aan het team om te beslissen hoe ze te implementeren; er is geen vaste workflow.
- waardevol-elk gebruikersverhaal levert een losstaande Waarde-Eenheid aan eindgebruikers.,
- Schatbaar-het is vrij gemakkelijk om te raden hoeveel tijd de ontwikkeling van een gebruikersverhaal zal duren.
- klein-het moet de hele cyclus doorlopen (ontwerpen, coderen, testen) tijdens één sprint.
- testbaar-er moeten duidelijke acceptatiecriteria zijn om te controleren of een gebruikersverhaal correct is geïmplementeerd.
Het User Story-formaat (dat ook door het Stormotion-team wordt gebruikt) is vrij eenvoudig en kort:
er niet moeilijk uitziet, hè?, Hier zijn een paar voorbeelden van gebruikersverhalen die passen bij een gemaakt taxi app project:
- als bestuurder wil ik slecht opgevoede passagiers blokkeren zodat ze me nooit meer worden getoond.
- als passagier wil ik de creditcard koppelen aan mijn profiel, zodat ik sneller, gemakkelijker en zonder contant geld kan betalen voor een rit.
- als bestuurder wil ik foto ‘ s van mijn auto toevoegen aan mijn profiel, zodat ik meer gebruikers kan aantrekken.
- als passagier wil ik dat verschillende beschikbare bestuurders worden weergegeven, zodat ik de meest geschikte optie voor mij kan kiezen.,
klinkt vrij eenvoudig, maar de ontwikkeling van een gebruikersverhaal is vaak niet zo eenvoudig. Maar, later, we zullen delen een aantal van onze bewezen tips die u zullen helpen om alleen goede foto ‘ s te maken.
Is er iets anders?
ondanks dat we er net achter zijn gekomen dat Agile gebruikersverhalen onafhankelijk zijn en moeten worden begrepen als volledig afzonderlijke werkeenheden, soms worden ze gegroepeerd., Dus bij het werken met hen bent u waarschijnlijk te ontmoeten en gebruik maken van het concept van een episch. Wat is er?
Een Epic is een oeuvre van hoog niveau dat samengaat met een groep Verwante verhalen.
bij Stormotion gebruiken we Epics om meer complexe taken te beschrijven en een duidelijke hiërarchie te creëren die het mogelijk maakt om de ontwikkeling gemakkelijker te beheren en nieuwe waarde te leveren aan de gebruikers terwijl we werken naar een groter doel. Toch, de gebruiker verhaal formaat zelf blijft hetzelfde.,rement die moeten worden geleverd tijdens de 1 sprint
Stel je voor dat je aan het bouwen bent een dating app., awesome I am
so, epics geven ons een overzicht op hoog niveau van onze doelen en hoe we er naar toe gaan., Het helpt ons ook tijdens het prioritatieproces, omdat we kunnen controleren welke Epics onze aandacht het meest vereisen en daarom welke verhalen eerst moeten worden geïmplementeerd.
Oh, nog een ding!
vergeet niet een acceptatiecriteria toe te voegen.
een acceptatiecriterium is een reeks voorwaarden die worden gebruikt om te bevestigen wanneer een verhaal is voltooid.,
ook bieden deze voorwaarden ons een dieper en beter begrip omdat ze inclusief belangrijke informatie over hoe verhalen presteren. Laten we een van de voorbeelden uit het gebruikersverhaal van het begin van het artikel hergebruiken:
welke acceptatiecriteria kunnen op dit verhaal worden toegepast?
- De app toont stuurprogramma ‘ s die binnen de laatste 20 minuten online waren en geen doorlopende rit hebben.
- de app toont slechts 5 stuurprogramma ‘ s die het dichtst bij de gebruiker staan.
- een gebruiker kan door profielen van deze stuurprogramma ’s bladeren, inclusief hun foto’ s en tarieven.
zoals u kunt zien, kennen we nu niet alleen de waarde van dit verhaal voor gebruikers, maar begrijpen we ook enkele belangrijke kenmerken die speciale aandacht vereisen tijdens de implementatie.,
u bent echter vrij om te kiezen hoe gedetailleerd uw acceptatiecriteria zullen zijn. Het kan variëren van “gewoon laten werken op een handige manier”tot nog meer gedetailleerde sets van voorwaarden dan in het bovenstaande voorbeeld.
Dat hangt sterk af van je ontwikkelingsteam, dus er is geen “correct antwoord”. Als uw team begeleiding en duidelijke, met-geen-ruimte-voor-interpretatie taken nodig heeft, kunt u beter vasthouden aan gedetailleerde instructies over hoe verhalen moeten presteren. Anders, de” Just get it done ” aanpak kan ook werken.,
Wow, het is veel gezegd over gebruikersverhalen. Maar waarom zijn ze zo belangrijk voor Agile teams?
👍 Wat zijn de voordelen van het maken van gebruikersverhalen?
Als u ooit betrokken was bij het werken met Agile frameworks, weet u al dat zowel Scrum als Kanban teams veel baat hebben bij het schrijven van gebruikersverhalen.,
in Kanban accumuleren teams verhalen in een Backlog en draaien ze één voor één om de work-in-progress flow te ondersteunen. Dit helpt om voortdurend op koers te blijven en de KPI ‘ s van het ontwikkelingsteam te verbeteren.
Scrum (waar we meestal de voorkeur aan geven bij Stormotion) teams houden ook van gebruikersverhalen. We gebruiken ze actief om schattingen te maken, prioriteiten te stellen en sprints te plannen, waardoor we wendbaar en flexibel blijven voor eventuele veranderingen., Dit is vooral gunstig wanneer we werken met Startups die in de MVP-fase en hebben beperkte middelen voordat pitching hun project aan Angel Investors.
behalve de hierboven genoemde, zijn er enkele levendige voordelen die gemeenschappelijk zijn voor alle Agile teams:
- houdt u gefocust op de bedrijfswaarde., Het helpt om uw app niet alleen goed gebouwd vanuit het technische perspectief, maar ook nuttig voor de eindgebruikers.
- creativiteit inschakelen. Omdat het een minimale hoeveelheid informatie bevat, is uw team vrij om creatieve ideeën te rijden om de beste oplossing te vinden om een verhaal te implementeren.
- uw project wordt beheersbaarder. We bij Stormotion weten dat het een manier makkelijker om te werken met kleine en schatbare Agile gebruiker verhalen in plaats van met grote complexe taken.
- zij inspireren het team! Elke ontwikkelaar houdt van dit zoete gevoel van een kleine overwinning die hem motiveert om nog harder te werken.,
laten we nu ingaan op het proces van het maken van een gebruikersverhaal!
📝 hoe gebruikersverhalen te schrijven: onze Workflow
we komen bij het meest opwindende deel van ons artikel. Echter, voordat we onze stap-voor-stap instructie over het schrijven van een gebruiker verhaal te delen, is het cruciaal om erachter te komen 2 essentiële vragen: wie en wanneer maakt ze.
Wie is verantwoordelijk voor het maken van een gebruikersverhaal?,
Als vuistregel worden verhalen voornamelijk geschreven door producteigenaren, omdat het hun verantwoordelijkheid is om de achterstand gevuld te houden met taken. Toch, vergeet niet dat Agile is gebaseerd op communicatie en meningen uitwisseling tussen experts. Dus…
het betekent niet noodzakelijk dat ze alleen geschreven moeten worden door een producteigenaar. Hoe meer mensen deelnemen aan het gesprek, hoe beter.
bij Stormotion worden verhalen geschreven door alle teamleden die gerelateerd zijn aan de zakelijke kant van het project (sales managers, marketeers, een producteigenaar etc.,), omdat het laat ons kijken naar de toekomst app vanuit het perspectief van elke potentiële vorm van de gebruiker. De verantwoordelijkheid van de producteigenaar in dit geval is om te bevestigen dat ze voldoen aan de INVEST criteria.
Wanneer worden gebruikersverhalen aangemaakt?
Een Story-writing meeting in ons hoofdkwartier wordt meestal gehouden in de buurt van het begin van het project., We geven er de voorkeur aan om ervoor te zorgen dat een project goed verloopt van de eerste tot de laatste dag.
Later kunnen we onze scrum User Story list gebruiken om meer gedetailleerde schattingen te maken (bijvoorbeeld tegen het einde van de Discovery-fase), prioriteit te geven aan de ontwikkeling van functies voor sprints enzovoort.
ook vullen we de oorspronkelijke lijst aan terwijl we aan een project werken met nieuwe verhalen om up-to-date te blijven met de eisen van onze klant.,
Wat zijn de stappen om geweldige Agile gebruikersverhalen te schrijven?
laten we u eerst herinneren aan een veelvoorkomende gebruiker Stories template:
als a , Ik wil dat
kort en gemakkelijk te schrijven lijkt. Trouwens, je bent van harte welkom om uw eigen User Story template te maken. Echter, we bij Stormotion hebben een specifieke workflow die ons helpt de beste verhalen te leveren:
- maak de lijst van uw eindgebruikers. Definieer wat hun “pijn” of “behoefte” is, wat je probeert op te lossen.
- Bepaal welke acties zij willen ondernemen.,
- Ontdek welke waarde dit zal opleveren voor gebruikers en, uiteindelijk, voor uw product. Vraag jezelf ook af-zal een partij ons hiervoor betalen?
- bespreken acceptatiecriteria en een optimale uitvoeringsstrategie.
laten we ze nu bekijken!
Stap 1: Denk aan de”Who”
Dit is de eerste en misschien wel de meest fundamentele stap. Voor het schrijven van een gebruiker verhaal moet je eigenlijk weten wie de eindgebruikers van uw product zijn. En nog belangrijker – wat ze nodig hebben, die u probeert te dekken.,
tijdens onze Story-writing workshops, proberen we het gebruik van een dergelijke rol als gewoon “de gebruiker”weg te laten. Het kan worden toegepast op elke persoon – van uw klanten tot admins-en, daarom, het geeft niet de persoonlijkheid van bepaalde doelgroepen, de manier waarop ze omgaan met de applicatie.
Als u echt goede resultaten wilt bereiken, wilt u misschien nog meer in uw publiek duiken., In plaats van gebruikers te benoemen naar hun rol (bijvoorbeeld “een driver”) probeer je een soort koper persona te creëren.
Hier zijn nog een paar tips uit onze eigen ervaring:
- Het draait allemaal om de gebruiker. Niet over ontwikkelaars. En zelfs niet over een producteigenaar. Elk verhaal moet waardevol zijn voor een groep van uw eindgebruikers.
- zie gebruikers niet alleen als externe klanten. Het is waar dat je verhalen vooral over hen gaan. Maar het is ook waar dat je moet rekening houden met interne gebruikers zoals admins, editors etc.
- voel wat empathie. Geef uw “gebruiker” een naam., Denk aan zijn mobiele gewoonten, welk probleem uw app gaat krijgen opgelost voor hem en hoe je gaat om dit pad gemakkelijker en sneller te maken. Denk aan mensen die je kent uit het echte leven en die bij dit portret passen; voel hoe je je verhoudt tot deze doelgroep.
Stap 2: Denk aan de “wat”
nu hebben we een paar groepen eindgebruikers. De volgende stap die we doen is bepalen welke functionaliteit elke gebruiker verwacht, hoe hij gaat om te communiceren met de app.,
Dit zijn de belangrijkste regels om te onthouden bij het schrijven van een actie voor een Kanban of Scrum gebruiker Story:
- één actie per verhaal. Als je iets wilt schrijven als “als klant wil ik door items bladeren en ze toevoegen aan de winkelwagen” kun je het beter splitsen in 2 aparte verhalen.
- Beschrijf een intentie, geen eigenschap., Bijvoorbeeld, in plaats van “Ik wil mijn profiel beheren” Maak een paar verhalen zoals “Ik wil kunnen registreren”, “Ik wil mijn profielfoto uploaden”, “Ik wil mijn creditcard koppelen aan mijn profiel” – elk verhaal zal een andere waarde hebben.
- houd het kort. Gebruikers niet schelen welke bibliotheek u zal gebruiken om hen te laten bladeren door de lijst met items, dus laat alle technische details opzij.
- vermijd het beschrijven van de gebruikersinterface. We hebben verhalen gedefinieerd als onderhandelbaar, Weet je nog? Dat is de reden waarom alle goede gebruiker verhaal voorbeelden geen UI details bevatten., Probeer dus geen speciale manier te bedenken om ze te implementeren (we zullen dit later doen).
Stap 3: Denk aan de “waarom”
tot slot is het laatste stuk van onze User Stories template gewijd aan een waarde die gebruikers krijgen na het uitvoeren van een actie. Het lijkt misschien niet een big deal, maar het is vaak het meest lastige deel van de gebruiker verhaal ontwikkeling.,
uw sectie moet echter altijd overeenkomen met uw metrics en KPI ‘ s. Het moet ofwel het verbeteren van de UX, verhoging retentie tarieven, verkorten gebruikers reis naar de kwestie oplossing of wat dan ook. Elk verhaal moet iets bijdragen aan het algemene doel van uw product.,
Als u geen antwoord kunt geven op de waarde van deze functie voor eindgebruikers en uw product, dan doet u iets verkeerd.
bijvoorbeeld, er zijn een paar voorbeelden van gebruikersverhalen met een goed geschreven waarde voor ons lopende app-project voor het bestellen van voedsel:
- als klant wil ik meldingen ontvangen wanneer er nieuwe hot aanbiedingen zijn, zodat ik nooit de beste deals mis. .
- als restaurantmanager wil ik de beschrijving van het gerecht in het menu aanvullen met een foto, zodat het er aantrekkelijker uitziet voor de klanten. .,
Stap 4: bespreek een verhaal
tot slot bespreken we altijd gebruikersverhalen nadat ze zijn gemaakt. Ook al lijkt het niets om over te praten.
tijdens deze Q&de auteur van het verhaal om meer details te geven of iets te verduidelijken indien nodig. Het helpt ons te begrijpen hoe het moet werken en het eens te worden over acceptatiecriteria., Op deze manier bekijken we alle voorbeelden van mobiele app-gebruikersverhalen één voor één.
dan houden we een brainstormsessie met het hele team dat aan het project werkt. Het stelt ons in staat om de beste manieren te vinden om gebruikersverhalen te implementeren vanuit het tech-perspectief.
zo schrijf je gebruikersverhalen in een notendop. Onze Stormotion Squad gebruikt ook de volgende tips bij het werken aan deze taak:
- begin met Epics., Het is meestal makkelijker om over te schakelen van meer complexe taken naar meer specifieke, dus probeer het schrijven van Epics en splits ze vervolgens in verhalen.
- luister naar feedback. Soms hoef je geen verhalen te raden-vraag je echte eindgebruikers om feedback en gebruik hun ideeën als een bron van inspiratie.
- Voer details niet te vroeg in. Het is beter om de brainstormsessie voor elke sprint te houden om te bespreken hoe je geplande verhalen kunt implementeren.
Conclusion conclusie
gebruikersverhalen zijn een essentieel element van de Agile aanpak die veel voordelen kan opleveren voor uw project., Het is echter belangrijk om ze correct te schrijven, wat enige tijd en vaardigheden vereist.,T-criteria, wat betekent dat ze:
- Onafhankelijke
- Bespreekbaar
- Waardevolle
- Inschatbaar
- Klein
- Toetsen
De gewone Gebruiker te Verhalen sjabloon bevat de gebruiker, de actie en de waarde (of het voordeel) en ziet er als volgt uit:
User Stories kunnen u helpen bij het voortdurend verbeteren van de waarde van uw product, een schatting van de ontwikkeling van de inspanningen op de juiste manier en de prioriteit van functie ontwikkeling tijdens de MVP-en post-MVP fasen.,
