brugerhistorier er enkle, men alligevel ekstremt kraftfulde konstruktioner: de beskriver stykker af funktionalitet fra en brugers synspunkt, udtrykt på en solid, kompakt måde. De afspejler, hvad en bestemt klasse af brugerbehov og den værdi, der skal opnås. Formatet er meget enkel og nem at bruge. Der er flere variationer, herunder:
hvorfor brugerhistorier?
brugerhistorier giver en glimrende måde at definere dit produkt med klarhed., Et sæt veldefinerede, prioriterede brugerhistorier kan hjælpe dig med at formulere funktionaliteten af dit produkt ved hjælp af ‘almindeligt engelsk’ — uden tekniske detaljer og implementeringsdetaljer.
tilgangen ‘brugerhistorie’ giver meningsfulde produktdiskussioner, både inden for produktudviklingsteamet og med eksterne interessenter.korrekt skrevne brugerhistorier giver et solidt grundlag for kommunikation og samarbejde — med fokus på det, der betyder mest for brugeren., Sammenlignet med andre midler til at opfange og dokumentere brugerkrav og produktspecifikation har de mindst følgende fordele:
- brugerhistorier hjælper med at opnå klarhed på tværs af teamet om, hvad de skal bygge, for hvem, hvorfor og hvornår. Da de er lette at definere, forstå og revidere, kan de blive den almindelige måde at kommunikere og opsummere produktets funktionalitet af både tekniske og ikke-tekniske medlemmer. De er yderst nyttige til diskussioner om produktomfang eller som indgangspunkter for tekniske dybdyk. De er centrale elementer i agile engineering.,
- brugerhistorier tilskynde deltagelse af ikke-tekniske medlemmer. Moderne soft .areprojekter er typisk komplekse, der involverer en bred vifte af teknologier, akronymer og implementeringsmuligheder. I mange tilfælde forstås terminologien eller det tekniske sprog ikke almindeligt — selv inden for et enkelt team — og introducerer således ‘støj’ og risici for projektet. Brugerhistorier fjerner denne tekniske dimension, så ethvert medlem af teamet kan bidrage, blot ved at tænke ‘som bruger’., Teamet kan bruge ikke-teknisk sprog og effektivt samarbejde om at definere, udfordre eller prioritere brugerhistorier. Virkningen på samarbejde og teamdynamik kan være betydelig.
- de hjælper med at definere hele produktet-som et sæt solide, klogt prioriterede historier. Produktudvikling team kan tænke stort, definere super-sæt af bruger-historier, og derefter tildele prioriteter (som afspejler den forventede værdi for brugeren, kompleksitet, afhængigheder og andre forretningsmæssige prioriteter). Du behøver ikke at gøre hårde beslutninger og flag elementer som ‘Out of scope’., I stedet kan du tildele en lavere prioritet til disse ‘skøre’ ideer, mens du flytter op brugerhistorierne, der afspejler kernefunktionaliteten i dit produkt. At definere de ‘afskårne linjer’, der bestemmer mulighederne for hver iteration, fase eller version, er så et spørgsmål om de tilgængelige ressourcer og holdets hastighed.
skrivning af gode brugerhistorier
formatet er ligetil, og det er nemt at skrive historier. Men at skrive gode kan være lidt vanskeligt. Her er nogle retningslinjer, du skal overveje:
brugerhistorier tasks Opgaver
brugerhistorier er ikke opgaver., Faktisk kan en enkelt historie have brug for hundredvis af enkeltopgaver, der skal leveres med succes. Opgaver handler om implementering; brugerhistorier handler om definition.
Når du udarbejder dine historier, skal du fokusere på at give klarhed om dine produktfunktioner — hvad, ikke hvordan.
Bliv på højt niveau
Du skal være på højt niveau, men også præcis og til punktet. Historier skal være enkle og solide. Dette vil hjælpe teammedlemmer og interessenter med at forstå brugernes behov dybt og undgå at bruge tid på at afklare bu.. .ords, terminologi og akronymer. Bare bruge enkle og præcise sprog.,
forstå brugerne
Du skal opdage og studere de rigtige brugere af dit produkt — fange deres profiler, synspunkter, forventninger og de tilhørende smertepunkter.’Bruger forskning og andre teknikker kan generere indsigt til at hjælpe dig med bedre at forstå brugerne og deres behov.
uanset teknikkerne har du brug for det sæt nøglebrugere — ideelt i form af personas — før du begynder at kompilere brugerhistorier.,
Tænk som bruger
<som en bestemt klasse af bruger /persona/rolle> en del af en brugerhistorie definerer vinklen, perspektivet — hvordan den bestemte bruger opfatter funktionaliteten opsummeret i historien.
Dette er af afgørende betydning — produktejeren og hele teamet skal tænke ud fra en brugers synspunkt og forstå de underliggende behov og den forventede værdi.,
Tænk stort
Når du beskriver et produkt som en efterslæb af brugerhistorier, er der ingen god grund til at begrænse din tænkning efter budget, tid, gennemførlighed eller omkostninger.
en god praksis er at tænke stort og lade ‘skøre’ brugerhistorier komme ind i Backloggen. Den administrative omkostning ved at opretholde en udvidet produktefterslæb er lille; værdien, der følger af det – med hensyn til produktklarhed, vision og muligheder — er massiv.,
brug epics
Epics kan have form af historier på højere niveau, der beskriver store stykker funktionalitet-de kræver typisk en betydelig mængde arbejde på tværs af flere sprints. En anden måde at tænke på epics er som grupperinger/ containere med relaterede, mindre historier, der alle tjener et fælles mål. Epics er gode til at organisere dine historier og give det store billede.,
afvis ikke — prioriterer i stedet
i Betragtning af en effektiv prioritering, det er god praksis at holde berige dit produkt backlog med nye bruger historier, der beskriver nye bruger-interaktion scenarier, ’tilfældige ideer,” eller produktion af produkt-innovation.
for at styre den potentielle støj skal du gruppere og prioritere de nye poster korrekt. Under alle omstændigheder skal du ikke filtrere/kassere genstande fra din backlog: de-scoped-genstande glemmes normalt, mens de-prioriterede genstande forbliver synlige og kan blive relevante under de rigtige forhold.,afhængig af konteksten kan prioritering af brugerhistorier være en vanskelig proces. Du skal estimere værdien af hver historie, for brugeren og for virksomheden. Du skal dimensionere kompleksiteten, estimere gennemførligheden og omkostningerne / indsatsen, der kræves for at opbygge og frigive funktionen. Du skal identificere tværafhængigheder i din backlog-håndhæve specifik bestilling mellem bestemte poster.
opsætning for succes — ikke kun accept
Teams definerer ofte brugeraccepttest og relaterede acceptkriterier. Accept er dog ikke nok-du skal oprette for succes., Som produktchef har du brug for mere end en bekræftelse på, at ‘det fungerer som det skal’ eller ‘i henhold til specifikationerne.’
Du har brug for målinger, der også er knyttet til direkte brugerfeedback, og fanger, hvor glade og engagerede dine rigtige brugere er. Selvom accept er god til at kontrollere funktionens udviklingslivscyklus, handler succes om midt / langsigtet påvirkning og værdi skabt for rigtige brugere af dit produkt. Du skal definere begge dele – på produkt-og/eller epic-og / eller historieniveau.
Tag historier, Tilføj metadata
komplekse produkter kræver hundredvis af brugerhistorier., For lettere navigation og administration skal du effektivt navngive, kategorisere og tagge dine historier. Efter de første par revisioner af en historie, du bør undgå at omdøbe eller drastisk ændre dens beskrivelse, da dette kan indføre forvirring og huller i teamet.
korrekt styring af metadataene i dine historier—status, fremskridt, links, prioriteter, ressourcer osv. – hjælper med at udforske, overvåge og forstå din efterslæb.
hold dig ikke til sticky notes!,
Ja, en mur fuld af farverige sticky notes ser fancy og hjælper dit team vises travl og produktiv 🙂 Men du har brug for en seriøs system og særlige værktøjer til at hjælpe dig med at forvalte dem korrekt, berige, prioritere og dele historier.,
I særlige tilfælde, som en brainstorming eller ideation session, det er okay, at tage det første sæt af bruger-historier ved hjælp af sticky notes—forudsat at du så dokumentere dem alle i en ordentlig product management system. Hvis du ikke gør det, og du bare holder dine historier på sticky notes, er chancerne for, at du vil gå glip af muligheder med hensyn til klarhed, innovation, effektivitet og samarbejde.,
du har stadig brug for SPECIFIKATIONER
at have et prioriteret sæt veldefinerede brugerhistorier er fantastisk, men det er kun begyndelsen. Holdet skal analysere historierne-fra et teknisk synspunkt-og skabe de nødvendige tekniske artefakter.
ideelt set er historier kortlagt til specifik dokumentation, der indeholder alle de tekniske detaljer, der er nødvendige fra et Soft .are engineering perspektiv. De giver adgangspunkter for detaljerede tekniske specifikationsdokumenter og andre detaljerede artefakter.,
visualisering hjælper
en altid (digital) visualisering af de højeste prioriterede brugerhistorier efter kategori, tema eller epic kan være yderst nyttig til samarbejde og tilpasning mellem teams og interessenter. Sammen med statistikker, problemer, blokkere og fremskridtsindikatorer kan et historiekort serveres via interaktive skærme i samarbejdsområdet.
brugerhistorier giver en fantastisk måde at hurtigt og præcist beskrive funktionaliteten af et Soft .areprodukt eller-system., De er også meget effektive til at fange output fra brainstorming sessioner, design sprints, hackathons og andre innovation-ledede processer — hvor en strøm af ideer skal fanges på en kompakt, struktureret måde.