En Guide til at skrive effektive brugerhistorier

Hvordan skriver vi effektive brugerhistorier?

Der er 5 overordnede principper, som jeg anbefale følgende:

1. Alle skal være glade for
   Få alle om bord er vigtigt, så får alle, der vil skrive, og ved hjælp af dit bruger historier til at skrive deres ideer og blive enige om det format, du vil bruge.
2. vær konsekvent
   Når du har en aftalt struktur, skal du sørge for at holde dig til den.
3. fokus på, hvad der er vigtigt
   når du skriver dem ud, undgå uvigtige detaljer., Tag dig tid til at gøre dem koncise, fjern enhver vaffel, da det bare kommer i vejen.
4. ingen implementeringsdetaljer
   fokuser altid på “hvorfor” ikke “hvordan”. Hvorfor vil en bruger have noget, ikke hvordan skal vi bygge det. Hvis du har brug for at give tekniske detaljer, skal disse vedhæftes som separat spec-fil.
5. klar, mulig & testbar
   sørg for, at alle kan forstå hver historie, og at den er opnåelig inden for den tidsramme, du er tilfreds med. Hvis du leverer i 2 uge sprints, så bør det ikke tage længere tid end de 2 uger.,

brugerhistorie anatomi

der er 3 obligatoriske dele til en brugerhistorie, titel, beskrivelse og acceptkriterier. Dit team accepterer muligvis, at en brugerhistorie skal have andre felter, før arbejdet kan starte på den. For eksempel kan du kræve en medarbejder, historiepunkter eller forretningsmæssige konsekvenser, men jeg anser disse for at være valgfri, da ikke alle organisationer vil kræve disse.

Titel
titler skal være korte, unikke og ikke vildledende.,

Nogle gode eksempler:

• Tilføj kontakt os panel forside”
• “Tilføj betalingskort støtte til indkøbskurv”
• “Update e-mail-skabelon tagging”

Nogle mindre gode (desværre virkelige verden) eksempler:

• “Gøre aftalte ændringer”
• “32072 — Opdateret Kortlægning – Opsalg Bruger historien (27263)”
• “Links — tracking query string for bill udløse og smart indlæg installere …”

Beskrivelse

Den beskrivelse, der har den reelle magt af brugeren historie. Det skal skabe empati i teamet for brugeren og en forståelse af det problem, der skal løses.,

en meget populær struktur for beskrivelsen har form af “som en … Jeg vil … så jeg kan …”.

denne struktur spørger spørgsmålet om “som en hvem”? Hvem står brugeren over for problemet? Du kan henvise til en persona her, hvis du bruger dem, alternativt, give brugeren et navn og tilføje en kontekst til brugerens situation. Forsøg at undgå at bruge” som kunde “eller” som bruger”, da dette er mindre effektivt til at skabe empati for en faktisk bruger.

beskrivelsen skal skrives på et enkelt, klart sprog uden tekniske termer eller forkortelser., Du bør spørge dig selv ” kan din Nan forstå det?”Et nyt teammedlem skal kunne læse beskrivelsen og forstå præcis, hvad problemet er, der skal løses.

følgende reelle eksempler er taget fra et projekt for at tilføje funktionalitet til et online kontosystem for kunder i et britisk energiselskab.,

nogle gode eksempler:

• “som John, en kunde med en traditionel elmåler, vil jeg forstå, hvorfor jeg ikke kan se diagrammer over mit energiforbrug mere detaljeret end måned for måned, så jeg kan beslutte, om jeg vil ændre dette og få en smart meter installeret.”
• ” som Bart, en proaktiv traditionel målerkunde, der ønsker at sikre, at min næste regning er nøjagtig, vil jeg vide, om der allerede er indsendt en måleraflæsning i dag, og at jeg ikke behøver at indsende en anden.,”

nogle mindre gode eksempler:

• “som bruger vil jeg forhindre trad kunder fra at være i stand til at bore ned under det højeste niveau, så deres kundeoplevelse styres”
• ” som kunde, der enten har givet en meter læst i dag eller havde en brændstof læst anslået i dag, jeg bør ikke have lov til at indsende en anden meter læst i dag som SAP kan ikke acceptere mere end en meter læst pr brændstof per dag.”

de mindre gode eksempler blev faktisk omskrevet til at være de gode eksempler ovenfor, da de problemer, de skitserede, ikke var klare., Denne forfiningsproces skal udføres, når som helst en del af en brugerhistorie ikke er klar. Bare sørg for, at alle i teamet er opmærksomme og accepterer ændringerne.

acceptkriterier

acceptkriterier bruges til at bevise fuldstændigheden af brugerhistorien. Dette er nyttigt for udviklere og testere.

skrivning af acceptkriterierne er en effektiv måde at gennemgå alle detaljer i historien, inden du starter noget arbejde. Mange potentielle faldgruber eller uventet arbejde kan “opdages” tidligt ved at skrive gode acceptkriterier.,

en meget populær struktur for acceptkriterierne har form af “givet… når… så…” som det ses i eksemplerne nedenfor.

Hvis en brugerhistorie har mere end 10 acceptkriterier, kan det være en indikation af, at historien gør for mange ting. I dette tilfælde anbefaler jeg at overveje at opdele historien.

hele holdet skal være involveret i skrivningen af acceptkriterierne. Hvis dette ikke er muligt, anbefaler jeg stærkt, at alle læser og accepterer dem, før de arbejder på dem. Dette gælder især for alle, der er involveret i test af arbejdet.,

nummerering af acceptkriterierne gør det nemt at henvise til dem.

nogle gode eksempler:

1. givet en kunde med en traditionel måler på stregdiagrammet for energiforbrug
   Når du klikker på værktøjstipen i en måned
   , vises en popup, der matcher det specificerede design.
2. givet en dobbelt brændstof kunde visning af energiforbruget bar chart
   når de har måneder med estimerede værdier
   så diagrammet legenden skal tydeligt vise en estimeret elektricitet ikon med en lys rød bar
   så diagrammet legenden skal tydeligt vise en estimeret gas ikon med en lyseblå bar.,

når vi ikke har brug for brugerhistorier

tekniske opgaver

Nogle gange synes en teknisk opgave ikke at vedrøre en kunde. Hvis dette er tilfældet, skal du ikke bruge en brugerhistorie. Men det er altid værd at overveje, hvorfor du udfører en teknisk opgave; opgraderer du et bibliotek for at forbedre hastigheden for brugerne? I så fald skal det være en brugerhistorie.

fejl

Hvis der opdages en fejl under testen af en brugerhistorie, der i øjeblikket arbejdes på, skal den være knyttet til den brugerhistorie.,

Hvis en fejl er fundet for noget, der er ikke en nuværende bruger historien, så det bør ikke være forbundet med en user story, men tilføjede, at efterslæbet som en selvstændig opgave.

kontinuerlig forbedring

brugerhistorier vil udvikle sig, efterhånden som der læres mere om det arbejde, der skal udføres. Dette er godt, fortsæt med at forbedre dem helt op til det punkt, du frigiver arbejdet til brugerne., Bare sørg for, at alle på dit team er opmærksomme og accepterer eventuelle ændringer, der foretages.

fortsæt med at forfine processen. Vær fleksibel, reflekter over, hvordan dine brugerhistorier fungerer for dit team, diskuter dem i retros og fortsæt med at forbedre den måde, du skriver dem på.