användarhistorier är enkla, men ändå extremt kraftfulla konstruktioner: de beskriver bitar av funktionalitet ur användarens synvinkel, uttryckt på ett solidt, kompakt sätt. De återspeglar vad en viss klass av användare behöver och det värde som ska uppnås. Formatet är mycket enkel och lätt att använda. Det finns flera varianter, inklusive:
varför användarhistorier?
användarhistorier ger ett utmärkt sätt att definiera din produkt med tydlighet., En uppsättning väldefinierade, prioriterade användarhistorier kan hjälpa dig att formulera funktionaliteten hos din produkt med ” vanlig engelska — – utan tekniska detaljer och implementeringsdetaljer.
användarhistoriken ger meningsfulla produktdiskussioner, både inom produktutvecklingsteamet och med externa intressenter.
korrekt skrivna användarhistorier ger en solid grund för kommunikation och samarbete — med fokus på vad som betyder mest för användaren., Jämfört med andra sätt att fånga och dokumentera användarkrav och produktspecifikation, har de åtminstone följande fördelar:
- användarhistorier hjälper till att uppnå tvärteam klarhet om vad man ska bygga, för vem, varför och när. Eftersom de är lätta att definiera, förstå och revidera, kan de bli det vanliga sättet att kommunicera och sammanfatta produktens funktionalitet av både tekniska och icke-tekniska medlemmar. De är mycket användbara för diskussioner om produktomfattningen eller som inträdespunkter för tekniska djupdykningar. De är viktiga delar av agile engineering.,
- användarhistorier uppmuntrar deltagande av icke-tekniska medlemmar. Moderna mjukvaruprojekt är vanligtvis komplexa, med ett brett spektrum av tekniker, akronymer och implementeringsalternativ. I många fall är terminologin eller det tekniska språket inte allmänt förstådd-även inom en enda grupp-vilket innebär att man inför ”buller” och risker för projektet. Användarhistorier tar bort den här tekniska dimensionen, så någon medlem i laget kan bidra, helt enkelt genom att tänka ”som användare”., Teamet kan använda icke-tekniskt språk och effektivt samarbeta för att definiera, utmana eller prioritera användarhistorier. Effekten på samarbete och lagdynamik kan vara betydande.
- de hjälper till att definiera hela produkten — som en uppsättning solida, klokt prioriterade berättelser. Produktutvecklingsteamet kan tänka stort, definiera superuppsättningen användarhistorier och tilldela sedan prioriteringar (vilket återspeglar det förväntade värdet för användaren, komplexitet, beroenden och andra affärsprioriteringar). Du behöver inte göra hårda beslut och flagga objekt som ”utom räckvidd”., Istället kan du tilldela en lägre prioritet till de ”galna” idéerna, samtidigt som du flyttar upp användarhistorierna som återspeglar produktens kärnfunktionalitet. Att definiera ”cut lines” som bestämmer omfattningen för varje iteration, fas eller version, är då en fråga om tillgängliga resurser och lagets hastighet.
skriva bra användarhistorier
formatet är enkelt, och skriva berättelser är lätt. Men att skriva bra kan vara lite knepigt. Här är några riktlinjer att tänka på:
användarhistorier trip-uppgifter
användarhistorier är inte uppgifter., Faktum är att en enda historia kan behöva hundratals enskilda uppgifter för att kunna levereras framgångsrikt. Uppgifter handlar om implementering; användarhistorier handlar om definition.
När du sammanställer dina berättelser, fokusera på att ge klarhet om dina produktfunktioner – vad, inte hur.
håll hög nivå
Du måste vara hög nivå, men också korrekt och till-punkten. Berättelser måste vara enkla och solida. Detta kommer att hjälpa gruppmedlemmar och intressenter djupt förstå användarnas behov, och undvika att spendera tid att klargöra buzzwords, terminologi och akronymer. Använd bara enkelt och korrekt språk.,
förstå användarna
Du måste upptäcka och studera de verkliga användarna av din produkt — fånga deras profiler, synpunkter, förväntningar och tillhörande ” smärtpunkter.”Användarforskning och andra tekniker kan generera insikter som hjälper dig att bättre förstå användarna och deras behov.
oavsett teknikerna behöver du uppsättningen nyckelanvändare — helst i form av personas — innan du börjar sammanställa användarhistorier.,
Tänk som en användare
<som en viss klass av användare /persona/Roll> del av en användarhistoria, definierar vinkeln, perspektivet — hur den specifika användaren uppfattar funktionaliteten som sammanfattas i berättelsen.
detta är av avgörande betydelse — produktägaren och hela teamet måste tänka ur användarens synvinkel och förstå de underliggande behoven och det förväntade värdet.,
Tänk stort
När du beskriver en produkt som en eftersläpning av användarhistorier finns det ingen bra anledning att begränsa ditt tänkande genom budget, tid, genomförbarhet eller kostnad.
en bra praxis är att tänka stort och låta ”galna” användarhistorier komma in i eftersläpningen. Den administrativa overhead för att upprätthålla en utökad produkt eftersläpning är liten; det värde som härrör från det — när det gäller produkt klarhet, vision och möjligheter — är massiv.,
använd epics
Epics kan ha formen av högre nivå berättelser, som beskriver stora bitar av funktionalitet-de kräver vanligtvis en betydande mängd arbete, över flera sprints. Ett annat sätt att tänka på epics är som grupperingar / behållare av relaterade, mindre historier, som alla tjänar ett gemensamt mål. Epics är bra för att organisera dina berättelser och ge den stora bilden.,
kasta inte bort — prioritera istället
Med tanke på en effektiv prioriteringsprocess är det bra att fortsätta berika din produkt eftersläpning med nya användarhistorier, beskriva nya användarinteraktionsscenarier, ”slumpmässiga idéer” eller produktionen av produktinnovationsaktiviteter.
för att hantera det potentiella bruset måste du korrekt gruppera och prioritera de nya posterna. I vilket fall som helst, inte filtrera bort/kassera objekt från din eftersläpning: de-scoped objekt är oftast bortglömda, medan de-prioriterade objekt förblir upptäckbara och kan bli relevanta under rätt förutsättningar.,
beroende på sammanhanget kan prioritering av användarhistorier vara en knepig process. Du måste uppskatta värdet på varje berättelse, för användaren och för verksamheten. Du måste storlek komplexiteten, uppskatta genomförbarheten och den kostnad/ansträngning som krävs för att bygga och släppa funktionen. Du måste identifiera korsberoende i din eftersläpning-genomdriva specifik beställning mellan vissa poster.
inställning för framgång — inte bara acceptans
Team definierar ofta användarnas acceptanstest och relaterade acceptanskriterier. Acceptans är dock inte tillräckligt-du måste ställa in för framgång., Som produktchef behöver du mer än en bekräftelse på att ”det fungerar som det ska ”eller” enligt specifikationerna.’
du behöver mätvärden som också är kopplade till direkt feedback från användare, fånga hur glada och engagerade dina riktiga användare är. Medan acceptans är bra att kontrollera utvecklingen livscykel av funktionen, framgång handlar om mitten / långsiktiga effekter och värde som skapats för riktiga användare av din produkt. Du måste definiera både-på produkten och/eller episka och / eller berättelse nivå.
Tagghistorier, Lägg till metadata
komplexa produkter kräver hundratals användarhistorier., För enklare navigering och administration måste du effektivt namnge, kategorisera och märka dina berättelser. Efter de första revideringarna av en historia bör du undvika att byta namn eller drastiskt ändra sin beskrivning eftersom det kan leda till förvirring och luckor i laget.
korrekt hantera metadata för dina berättelser—status, framsteg, länkar, prioriteringar, resurser, etc. – hjälper till att utforska, övervaka och förstå din eftersläpning.
håll inte fast vid klisterlappar!,
ja, en vägg full av färgglada klisterlappar ser fancy och hjälper ditt team verkar upptagen och produktiv 🙂 men du behöver ett seriöst system och specialverktyg för att hjälpa dig att hantera, berika, prioritera och dela berättelser.,
i särskilda fall, såsom en brainstorming eller ideationssession, det är okej att fånga den första uppsättningen användarhistorier med hjälp av klisterlappar—förutsatt att du sedan dokumenterar dem alla i ett korrekt produkthanteringssystem. Om du inte gör det, och du bara hålla dina berättelser om klisterlappar, är chansen att du kommer att missa möjligheter när det gäller tydlighet, innovation, effektivitet och samarbete.,
du behöver fortfarande SPECIFIKATIONER
att ha en prioriterad uppsättning väldefinierade användarhistorier är bra, men det är bara början. Laget behöver analysera berättelserna-ur teknisk synvinkel-och skapa nödvändiga tekniska artefakter.
idealt sett mappas berättelser till specifik dokumentation som ger alla tekniska detaljer som behövs ur ett mjukvarutekniskt perspektiv. De tillhandahåller ingångspunkterna för detaljerade tekniska specifikationsdokument och andra detaljerade artefakter.,
visualisering hjälper
en alltid på (digital) visualisering av de högsta prioritet användarhistorier efter kategori, tema, eller epic kan vara mycket användbart för samarbete och anpassning mellan lag och intressenter. Tillsammans med statistik, problem, blockerare och framstegsindikatorer kan en historiekarta serveras via interaktiva skärmar i samarbetsutrymmet.
användarhistorier ger ett bra sätt att snabbt och korrekt beskriva funktionaliteten hos en programvaruprodukt eller ett system., De är också mycket effektiva för att fånga resultaten av brainstorming sessioner, design sprints, hackathons och andra innovationsledda processer-där en ström av idéer måste fångas på ett kompakt och strukturerat sätt.