gebruikersverhalen zijn eenvoudige, maar uiterst krachtige constructies: ze beschrijven stukjes functionaliteit vanuit het oogpunt van een gebruiker, uitgedrukt op een solide, compacte manier. Ze weerspiegelen wat een bepaalde klasse van gebruikers nodig heeft en de waarde die moet worden verkregen. Het formaat is zeer eenvoudig en makkelijk te gebruiken. Er zijn verschillende variaties, waaronder:
waarom gebruikersverhalen?
gebruikersverhalen bieden een uitstekende manier om uw product duidelijk te definiëren., Een set van goed gedefinieerde, geprioriteerde gebruikersverhalen kan u helpen de functionaliteit van uw product te articuleren met behulp van ‘plain English’ — zonder technische details en implementatiedetails.
De “user story” – benadering biedt zinvolle productdiscussies, zowel binnen het productontwikkelingsteam als met externe stakeholders.
correct geschreven gebruikersverhalen bieden een solide basis voor communicatie en samenwerking — waarbij de nadruk ligt op wat voor de gebruiker het belangrijkst is., In vergelijking met andere manieren om gebruikersvereisten en productspecificaties vast te leggen en te documenteren, hebben ze ten minste de volgende voordelen:
- gebruikersverhalen helpen om teamoverschrijdende duidelijkheid te bereiken over wat te bouwen, voor wie, waarom en wanneer. Omdat ze gemakkelijk te definiëren, te begrijpen en te herzien zijn, kunnen ze de standaard manier worden om te communiceren en de functionaliteit van het product samen te vatten door zowel technische als niet-technische leden. Ze zijn uiterst nuttig voor discussies over productscope of als toegangspunten voor technische diepzeeduiken. Ze zijn sleutelelementen van agile engineering.,
- gebruikersverhalen stimuleren deelname door niet-technische leden. Moderne softwareprojecten zijn meestal complex, waarbij een breed scala aan technologieën, acroniemen en implementatieopties. In veel gevallen wordt de terminologie of de technische taal niet algemeen begrepen — zelfs niet binnen één team — waardoor “lawaai” en risico ’s aan het project worden toegevoegd. Gebruikersverhalen verwijderen deze technische dimensie, zodat elk lid van het team kan bijdragen, simpelweg door te denken ‘als gebruiker’., Het team kan niet-technische taal gebruiken en effectief samenwerken bij het definiëren, uitdagen of prioriteren van gebruikersverhalen. De impact op samenwerking en teamdynamiek kan aanzienlijk zijn.
- ze helpen bij het definiëren van het hele product — als een set van solide, wijselijk geprioriteerde verhalen. Het productontwikkelingsteam kan groot denken, de superset van gebruikersverhalen definiëren en vervolgens prioriteiten toewijzen (die de verwachte waarde voor de gebruiker, complexiteit, afhankelijkheden en andere bedrijfsprioriteiten weerspiegelen). Je hoeft geen moeilijke beslissingen te nemen en items te markeren als ‘out of scope’., In plaats daarvan, kunt u een lagere prioriteit toe te wijzen aan die ‘gekke’ ideeën, terwijl het verplaatsen van de gebruiker verhalen die de kernfunctionaliteit van uw product. Het definiëren van de’ cut lines ‘ die de reikwijdte voor elke iteratie, fase of versie bepalen, is dan een kwestie van de beschikbare middelen en de snelheid van het team.
geweldige gebruikersverhalen schrijven
het formaat is eenvoudig en het schrijven van verhalen is eenvoudig. Maar het schrijven van grote kan een beetje lastig zijn. Hier zijn enkele richtlijnen om te overwegen:
gebruikersverhalen ≠ taken
gebruikersverhalen zijn geen taken., In feite, een enkel verhaal kan honderden enkele taken nodig om succesvol te worden geleverd. Taken gaan over implementatie; gebruikersverhalen gaan over definitie.
bij het samenstellen van uw verhalen, focus op het verstrekken van duidelijkheid over uw Product functies — het wat, niet het hoe.
Stay high-level
u moet high-level zijn, maar ook accuraat en to-the-point. Verhalen moeten eenvoudig en solide zijn. Dit zal teamleden en stakeholders helpen de behoeften van de gebruiker diep te begrijpen en te voorkomen dat tijd wordt besteed aan het verduidelijken van modewoorden, terminologie en acroniemen. Gebruik gewoon eenvoudige en nauwkeurige taal.,
begrijp de gebruikers
u moet de echte gebruikers van uw product ontdekken en bestuderen — leg hun profielen, standpunten, verwachtingen en de bijbehorende pijnpunten vast.’Gebruikersonderzoek en andere technieken kunnen inzichten genereren om je te helpen de gebruikers en hun behoeften beter te begrijpen.
ongeacht de technieken, je hebt de set van sleutelgebruikers nodig-idealiter in de vorm van persona ‘ s-voordat je begint met het compileren van gebruikersverhalen.,
Think as a user
de <as a particular class of user/ persona /role> part of a user story definieert de hoek, het perspectief — hoe de specifieke gebruiker de functionaliteit waarneemt die in het verhaal wordt samengevat.
Dit is van cruciaal belang – de eigenaar van het product en het hele team moeten denken vanuit het standpunt van de gebruiker en de onderliggende behoeften en de verwachte waarde begrijpen.,
denk groot
bij het beschrijven van een product als een achterstand van gebruikersverhalen, is er geen goede reden om uw denken te beperken door budget, tijd, haalbaarheid of kosten.
een goede gewoonte is om groot te denken en ‘gekke’ gebruikersverhalen de achterstand in te laten gaan. De administratieve overhead van het handhaven van een uitgebreide product achterstand is klein; de waarde die daaruit voortvloeit — in termen van product duidelijkheid, visie, en kansen-is enorm.,
gebruik epics
Epics kunnen de vorm aannemen van verhalen op een hoger niveau, die grote stukken functionaliteit beschrijven-ze vereisen meestal een aanzienlijke hoeveelheid werk, over meerdere sprints. Een andere manier om te denken aan epics is als groeperingen/ containers van verwante, kleinere verhalen, die allemaal een gemeenschappelijk doel dienen. Epics zijn goed voor het organiseren van uw verhalen en het verstrekken van het grote plaatje.,
niet negeren-prioriteren in plaats daarvan
gegeven een effectief prioritatieproces, is het een goede praktijk om uw product achterstand te blijven verrijken met nieuwe gebruikersverhalen, nieuwe gebruikersinteractiescenario ‘s,’ willekeurige ideeën ‘ of de output van productinnovatieactiviteiten te beschrijven.
om de mogelijke ruis te beheren, moet u de nieuwe items goed groeperen en prioriteren. In ieder geval, niet filteren / verwijderen van items uit uw achterstand: de-scoped items worden meestal vergeten, terwijl de-prioritering items blijven vindbaar en kunnen relevant worden onder de juiste omstandigheden.,
afhankelijk van de context kan het prioriteren van gebruikersverhalen een lastig proces zijn. Je moet de waarde van elk verhaal schatten, voor de gebruiker en voor het bedrijf. U moet de grootte van de complexiteit, schatting van de haalbaarheid en de kosten/inspanning die nodig is om te bouwen en de functie vrij te geven. U moet cross-afhankelijkheden identificeren in uw backlog — afdwingende specifieke volgorde tussen bepaalde items.
Setup voor succes-niet alleen acceptatie
Teams definiëren vaak gebruikerstoets en bijbehorende acceptatiecriteria. Acceptatie is echter niet genoeg — je moet het opzetten voor succes., Als productmanager heb je meer nodig dan een bevestiging dat ‘het werkt zoals het hoort’ of ‘volgens de specificaties.’
u hebt statistieken nodig die ook gekoppeld zijn aan directe feedback van gebruikers, om vast te leggen hoe blij en betrokken uw echte gebruikers zijn. Hoewel acceptatie is goed om de ontwikkeling van de levenscyclus van de functie te controleren, succes is over de Mid/lange termijn impact en waarde gecreëerd voor echte gebruikers van uw product. Je moet beide definiëren – op het product-en/of epic-en / of verhaalniveau.
Tag stories, voeg metagegevens toe
complexe producten vereisen honderden gebruikersverhalen., Voor eenvoudiger navigatie en Administratie, je nodig hebt om effectief naam te geven, categoriseren, en tag uw verhalen. Na de eerste paar herzieningen van een verhaal, moet u voorkomen dat hernoemen of drastisch veranderen van de beschrijving omdat dit verwarring en gaten in het team kan leiden.
het correct beheren van de metadata van uw verhalen—status, voortgang, links, prioriteiten, bronnen, enz. – helpt bij het verkennen, monitoren en begrijpen van uw achterstand.
blijf niet bij Sticky notes!,
ja, een muur vol kleurrijke Sticky notes ziet er mooi uit en helpt je team er druk en productief uit te zien:) maar je hebt een serieus systeem en speciale tools nodig om je te helpen goed te beheren, te verrijken, prioriteiten te stellen en verhalen te delen.,
in speciale gevallen, zoals een brainstormsessie of ideatiesessie, is het goed om de eerste set gebruikersverhalen vast te leggen met behulp van Sticky Notes—op voorwaarde dat u ze allemaal documenteert in een goed productbeheersysteem. Als je dat niet doet, en je houdt gewoon je verhalen op sticky notes, is de kans groot dat je kansen mist op het gebied van duidelijkheid, innovatie, efficiëntie en samenwerking.,
je hebt nog steeds specs nodig
het hebben van een geprioriteerde set van goed gedefinieerde gebruikersverhalen is geweldig, maar het is nog maar het begin. Het team moet de verhalen analyseren – vanuit een technisch oogpunt-en de nodige technische artefacten creëren.
idealiter worden verhalen toegewezen aan specifieke documentatie die alle technische details biedt die nodig zijn vanuit een software engineering perspectief. Zij bieden de toegangspunten voor gedetailleerde technische specificatiedocumenten en andere gedetailleerde artefacten.,
visualisatie helpt
een always-on (digitale) visualisatie van de hoogste prioriteit gebruikersverhalen per categorie, thema of epic kan zeer nuttig zijn voor samenwerking en afstemming tussen teams en stakeholders. Samen met statistieken, problemen, blokkers en voortgangsindicatoren kan een verhaalkaart worden geserveerd via interactieve schermen in de samenwerkingsruimte.
gebruikersverhalen bieden een geweldige manier om snel en accuraat de functionaliteit van een softwareproduct of systeem te beschrijven., Ze zijn ook zeer effectief in het vastleggen van de output van brainstormsessies, ontwerp sprints, hackathons, en andere innovatie-geleide processen — waar een stroom van ideeën moet worden vastgelegd in een compacte, gestructureerde manier.