Slik skriver du brukerhistorier (med eksempler og akseptansekriterier)
En brukerhistorie er en kort beskrivelse av en funksjon sett fra brukerens synspunkt: «Som [type bruker] vil jeg [mål] slik at [grunn].» Under den skriver du akseptansekriterier, noen spesifikke betingelser som må være oppfylt for at historien regnes som ferdig. Hold hver historie liten nok til å bygges og testes i ett hugg, og skriv kriteriene slik at hvem som helst kan sjekke dem.
Brukerhistorier ble populære blant agile programvareteam, men de er like nyttige når du bygger selv med en AI-appbygger. En god historie er en god ledetekst.
Formatet
En brukerhistorie har tre deler:
Som en [hvem], vil jeg [hva] slik at [hvorfor].
- Hvem er en bestemt type bruker: en førstegangsbesøkende, et betalende medlem, en resepsjonist på klinikken, en administrator. Ikke «brukeren».
- Hva er det de vil gjøre, med sine egne ord. Ikke hvordan skjermen fungerer.
- Hvorfor er resultatet de bryr seg om. Det er delen folk hopper over, og den som stopper deg fra å bygge feil ting.
Eksempel:
Som treningsmedlem vil jeg kunne avbestille en klassebooking fra mobilen slik at noen på ventelisten kan ta plassen min, og jeg ikke blir belastet et no-show-gebyr.
«Hvorfor» forteller deg to ting «hva» ikke gjorde: det må fungere på mobil, og venteliste- og gebyrreglene er involvert.
Akseptansekriterier
En historie sier hva som ønskes. Akseptansekriterier sier når det er ferdig. De bør være spesifikke nok til at to personer ville være enige om hvert av dem består.
En vanlig måte å skrive dem på er Gitt / Når / Så:
- Gitt en utgangssituasjon
- Når brukeren gjør noe
- Så er dette resultatet
For treningsbookingshistorien:
- Gitt at jeg har en booking mer enn 12 timer frem i tid, når jeg trykker Avbestill og bekrefter, så er bookingen fjernet, og jeg ser «Booking avbestilt».
- Gitt at jeg avbestiller en booking og timen har venteliste, når avbestillingen lagres, så får den første personen på ventelisten plassen og en e-post.
- Gitt en booking mindre enn 12 timer frem i tid, når jeg trykker Avbestill, så ser jeg at et gebyr for sen avbestilling gjelder før jeg bekrefter.
- Gitt at jeg er på en skjerm i telefonbredde, så er Avbestill-knappen synlig uten å scrolle sideveis.
En vanlig sjekkliste fungerer også, så lenge hvert punkt kan testes. «Å avbestille er enkelt» kan ikke testes. «Avbestilling tar maks to trykk fra bookingslisten» kan det.
Steg for steg: å skrive en god historie
Steg 1: Start fra en ekte bruker og et ekte problem
Velg én type bruker og noe de sliter med i dag. Hvis du har gjort kundeintervjuer, bruk deres ord. «Jeg glemmer alltid å avbestille og blir belastet» er et bedre utgangspunkt enn «legg til avbestillingsfunksjon».
Steg 2: Skriv historien på én linje
Fyll inn malen. Hvis du ikke kan skrive et overbevisende «slik at», spør deg om funksjonen i det hele tatt er nødvendig.
Steg 3: Legg til tre til seks akseptansekriterier
Dekk hovedsuksesstilfellet først, deretter de viktige variasjonene: en annen rolle, en tom tilstand, en grense, en feil. Hvis du skriver mer enn seks, er historien sannsynligvis for stor.
Steg 4: Noter hva som er utenfor omfanget
En linje sparer mye frem og tilbake: «Utenfor omfang: refusjoner for betalte timer; administratorer som avbestiller for medlemmer.» Det stopper historien fra å vokse mens du bygger.
Steg 5: Sjekk den mot INVEST
INVEST er en vanlig sjekkliste for gode historier. En historie bør være:
| Bokstav | Betyr | Rask test |
|---|---|---|
| I | Uavhengig | Kan bygges uten å vente på en annen historie |
| N | Forhandlbar | Beskriver behovet, ikke en fast løsning |
| V | Verdifull | En bruker ville merke det hvis det ble sluppet |
| E | Estimerbar | Du kan gjette omtrent hvor stor den er |
| S | Liten | Bygges og testes i én økt |
| T | Testbar | Hvert akseptansekriterium kan sjekkes |
Du trenger ikke gi hver historie poeng. Det er mest nyttig når en historie føles feil og du vil vite hvorfor.
Gode og dårlige eksempler
| Svak historie | Problem | Bedre historie |
|---|---|---|
| Som bruker vil jeg ha et dashbord. | Ingen spesifikk bruker, ingen grunn, ikke testbar | Som butikkeier vil jeg se dagens ordrer og omsetning på én skjerm slik at jeg ser med en gang om dagen går bra. |
| Som administrator vil jeg at databasen skal ha en statuskolonne. | Beskriver implementering, ikke et behov | Som administrator vil jeg kunne merke ordrer som sendt slik at kundene slutter å e-poste for å spørre hvor de er. |
| Som kunde vil jeg administrere kontoen min. | For stor: dekker mange funksjoner | Som kunde vil jeg endre e-postadressen min slik at kvitteringer går til den nye innboksen. |
| Som besøkende vil jeg at siden skal være rask. | Ikke en historie; en kvalitet alle trenger | Skriv det som et kriterium på hver historie, eller som et eget ytelsesmål. |
Slik deler du en historie som er for stor
Store historier er der prosjekter stopper opp. Vanlige måter å dele dem på:
- Etter brukerrolle. Medlemmer avbestiller sine egne bookinger; ansatte avbestiller alles.
- Etter steg i flyten. Bla gjennom timer; book en time; få en påminnelse.
- Enkelt tilfelle først. Avbestill en gratis time nå; håndter gebyrer og refusjoner i en senere historie.
- Etter datavariasjon. Støtt ett sted først, flere senere.
- Den gode veien først, deretter feil. Bygg den så den fungerer, og legg så til håndtering for fulle timer, utløpte kort og lignende.
Hver bit bør fortsatt være noe en bruker kan bruke og legge merke til.
Bruke brukerhistorier som ledetekster
En brukerhistorie med akseptansekriterier ligner veldig på en god ledetekst til en AI-appbygger. Den gir AI-en hvem, hva, hvorfor og en definisjon av ferdig. Send én historie per melding:
Som treningsmedlem vil jeg kunne avbestille en klassebooking fra mobilen slik at noen på ventelisten kan ta plassen min. Akseptansekriterier:
- Avbestill finnes på hver booking under Mine bookinger, med et bekreftelsessteg.
- Avbestilling mer enn 12 timer før timen fjerner bare bookingen.
- Mindre enn 12 timer før, vis «Et gebyr for sen avbestilling på 5 $ gjelder» før bekreftelse, og registrer gebyret på bookingen.
- Hvis timen har venteliste, får den første personen plassen og en e-post.
- Fungerer på en skjerm i telefonbredde. Utenfor omfang: refusjoner, personal som avbestiller for medlemmer. Bygg dette, og sjekk deretter hvert kriterium i forhåndsvisningen og fortell meg hvilke som består.
Du kan også be AI-en lage utkast til historier fra en grov idé, og så redigere dem selv:
Her er appideen min: [to eller tre setninger]. Skriv brukerhistoriene for en første versjon, gruppert etter brukertype, hver med 3 til 5 Gitt/Når/Så-akseptansekriterier. Merk hvilke som er nødvendige for lansering, og hvilke som kan vente.
Les alltid og rediger resultatet. AI-en kjenner ikke brukerne dine; det gjør du.
Akseptansekriteriene fungerer også som testplanen din. Når historien er bygget, gå gjennom hvert kriterium selv. Vår guide om å teste appen din før lansering bygger videre på dette.
Hvor brukerhistorier passer sammen med andre dokumenter
- En produktkravspesifikasjon beskriver hele produktet: problemet, brukerne, omfanget. Brukerhistoriene er de detaljerte delene inni den. Se hvordan du skriver en PRD med AI.
- En feilrapport beskriver noe som er ødelagt mot en historie som allerede var bygget. Se hvordan du skriver en god feilrapport.
- En MVP er det minste settet med historier som leverer kjerneverdien. Se hva er en MVP.
Vanlige feil
- «Som en bruker…» For vagt. Navngi den faktiske typen bruker.
- Å hoppe over «slik at». Uten grunnen kan du ikke gjøre fornuftige avveininger.
- Å skrive løsningen i stedet for behovet. «Jeg vil ha en nedtrekksliste» låser en design før noen har tenkt gjennom den.
- Kriterier som ikke kan testes. «Enkelt», «raskt» og «intuitivt» er ønsker, ikke kriterier.
- Historier som egentlig er epics. «Administrere kontoen min» er ti historier.
- Å skrive alle historier på forhånd. Skriv de neste få i detalj; behold resten som én-linjers til du kommer til dem.
Historier i Mythex
I Mythex er Plan-modus et godt sted å gjøre en idé om til historier: agenten diskuterer tilnærmingen før den redigerer noe. Når en historie er klar, bytt til Build og lim den inn, én historie per melding. Etter hver kan /test klikke seg gjennom forhåndsvisningen og sjekke flyten, og du kan rulle tilbake et svar med Gå tilbake til dette punktet hvis det gikk feil. Se effektive ledetekster i dokumentasjonen, og vår guide om å skrive ledetekster til AI-appbyggere.
Sjekkliste for brukerhistorier
- Navngir en spesifikk type bruker
- Beskriver et behov, ikke en design
- Inneholder en reell «slik at»-grunn
- Har tre til seks testbare akseptansekriterier
- Dekker minst én kantsituasjon eller feil
- Sier hva som er utenfor omfanget
- Liten nok til å bygges og testes i ett hugg
- Kriteriene sjekket etter bygging, ett for ett
Spørsmål
Hva er formatet på en brukerhistorie?
Den vanlige malen er: Som [type bruker] vil jeg [et mål] slik at [en grunn]. Den følges av akseptansekriterier, en kort liste med betingelser som må være oppfylt for at historien regnes som ferdig.
Hva er akseptansekriterier?
Akseptansekriterier er spesifikke, testbare betingelser som definerer når en brukerhistorie er ferdig. De skrives ofte i Gitt / Når / Så-form: gitt en utgangssituasjon, når brukeren gjør noe, så skjer et bestemt resultat.
Hvor stor bør en brukerhistorie være?
Liten nok til å bygges og testes i én økt, og likevel verdifull alene. Hvis en historie har mer enn fem eller seks akseptansekriterier, eller dekker flere skjermer, del den etter brukerrolle, etter steg i flyten, eller etter enkelt tilfelle først og kantsituasjoner senere.
Er brukerhistorier nyttige når jeg bygger med AI?
Ja. En brukerhistorie med akseptansekriterier ligner en ideell ledetekst: den sier hvem funksjonen er for, hva de trenger, og nøyaktig hvordan du sjekker at den fungerer. Å sende én historie per melding holder også AI-endringene små og enkle å teste.