Sådan skriver du user stories (med eksempler og acceptkriterier)

En user story er en kort beskrivelse af en funktion set fra brugerens synspunkt: „Som [type bruger] vil jeg [mål], så [grund].“ Under den skriver du acceptkriterier, nogle få specifikke betingelser, der skal være opfyldt, før historien tæller som færdig. Hold hver historie lille nok til at bygge og teste i ét forløb, og skriv kriterierne, så hvem som helst kan kontrollere dem.

User stories blev populære i agile softwareteams, men de er lige så nyttige, når du bygger alene med en AI-app-builder. En god historie er en god prompt.

Formatet

En user story har tre dele:

Som [hvem], vil jeg [hvad], så [hvorfor].

Hvem er en bestemt type bruger: en førstegangsbesøgende, et betalende medlem, en klinikreceptionist, en administrator. Ikke „brugeren“.
Hvad er det, de vil gøre, med deres egne ord. Ikke hvordan skærmen fungerer.
Hvorfor er det udfald, de går op i. Det er den del, folk springer over, og den, der forhindrer dig i at bygge det forkerte.

Eksempel:

Som fitnessmedlem vil jeg annullere en holdbooking fra min telefon, så en person på ventelisten kan tage min plads, og jeg ikke bliver opkrævet et no-show-gebyr.

„Hvorfor“-delen fortæller dig to ting, „hvad“-delen ikke gjorde: Det skal virke på telefon, og venteliste og gebyrregler er involveret.

Acceptkriterier

En historie siger, hvad der ønskes. Acceptkriterierne siger, hvornår det er færdigt. De skal være specifikke nok til, at to personer ville være enige om, om hvert enkelt består.

En almindelig måde at skrive dem på er Given / When / Then:

Given en startsituation
When brugeren gør noget
Then dette er resultatet

For fitness-bookinghistorien:

Given jeg har en booking mere end 12 timer væk, when jeg trykker Annuller og bekræfter, then bookingen fjernes, og jeg ser „Booking annulleret“.
Given jeg annullerer en booking, og holdet har en venteliste, when annulleringen gemmes, then får den første person på ventelisten pladsen og en mail.
Given en booking mindre end 12 timer væk, when jeg trykker Annuller, then ser jeg, at et gebyr for sen annullering gælder, før jeg bekræfter.
Given jeg er på en skærm i telefonbredde, then er Annuller-knappen synlig uden at scrolle sideværts.

En simpel tjekliste virker også, så længe hvert punkt kan testes. „Annullering er let“ kan ikke testes. „Annullering tager højst to tryk fra bookinglisten“ kan.

Trin for trin: skriv en god historie

Trin 1: Start fra en reel bruger og et reelt problem

Vælg én type bruger og noget, de har svært ved i dag. Hvis du har lavet kundeinterviews, så brug deres ord. „Jeg glemmer altid at annullere og bliver opkrævet“ er et bedre udgangspunkt end „tilføj annulleringsfunktion“.

Trin 2: Skriv den éns-linjes historie

Udfyld skabelonen. Hvis du ikke kan skrive et overbevisende „så“, så spørg om funktionen overhovedet er nødvendig.

Trin 3: Tilføj tre til seks acceptkriterier

Dæk hovedsucces-casen først, og derefter de vigtige variationer: en anden rolle, en tom tilstand, en grænse, en fejl. Hvis du skriver mere end seks, er historien sandsynligvis for stor.

Trin 4: Notér hvad der er uden for omfang

Én linje sparer en masse frem og tilbage: „Uden for omfang: refusion for betalte hold; admins der annullerer for medlemmer.“ Det forhindrer historien i at vokse, mens du bygger den.

Trin 5: Tjek den mod INVEST

INVEST er en almindelig tjekliste for gode historier. En historie skal være:

Bogstav	Betyder	Hurtig test
I	Uafhængig	Kan bygges uden at vente på en anden historie
N	Forhandlingsbar	Beskriver behovet, ikke et fast design
V	Værdifuld	En bruger ville bemærke det, hvis det blev sendt
E	Estimerbar	Du kan gætte nogenlunde, hvor stor den er
S	Lille	Bygget og testet på ét forløb
T	Testbar	Hvert acceptkriterie kan kontrolleres

Du behøver ikke score hver historie. Det er mest nyttigt, når en historie føles forkert, og du vil vide hvorfor.

Gode og dårlige eksempler

Svag historie	Problem	Bedre historie
Som bruger vil jeg have et dashboard.	Ingen bestemt bruger, ingen grund, ikke testbar	Som butiksejer vil jeg se dagens ordrer og omsætning på én skærm, så jeg med et blik kan se, om dagen går godt.
Som admin vil jeg have, at databasen har en statuskolonne.	Beskriver implementering, ikke et behov	Som admin vil jeg markere ordrer som afsendt, så kunder holder op med at mailede for at spørge, hvor de er.
Som kunde vil jeg administrere min konto.	For stor: dækker mange funktioner	Som kunde vil jeg ændre min mailadresse, så kvitteringer går til min nye indbakke.
Som besøgende vil jeg have, at siden er hurtig.	Ikke en historie; en kvalitet alle har brug for	Skriv det som et kriterium på hver historie, eller som et separat ydelsesmål.

Sådan deler du en historie, der er for stor

Store historier er der, hvor projekter går i stå. Almindelige måder at dele dem op på:

Efter brugerrolle. Medlemmer annullerer deres egne bookinger; personale annullerer alles.
Efter trin i flowet. Gennemse hold; book et hold; få en påmindelse.
Den enkle sag først. Annuller et gratis hold nu; håndtér gebyrer og refusioner i en senere historie.
Efter datavariation. Understøt én lokation først, flere senere.
Den glade sti først, derefter fejl. Få det til at virke, og tilføj derefter håndtering af fulde hold, udløbne klippekort og så videre.

Hvert stykke bør stadig være noget, en bruger kan bruge og lægge mærke til.

Brug user stories som prompts

En user story med acceptkriterier ligner tæt på en god prompt til en AI-app-builder. Den giver AI'en hvem, hvad, hvorfor og en definition af færdig. Send én historie pr. besked:

Som fitnessmedlem vil jeg annullere en holdbooking fra min telefon, så en person på ventelisten kan tage min plads. Acceptkriterier:

Annuller er på hver booking under Mine bookinger, med et bekræftelsestrin.

Annullering mere end 12 timer før holdet fjerner blot bookingen.

Mindre end 12 timer før vises „Et gebyr for sen annullering på 5 USD gælder“ før bekræftelse, og gebyret gemmes på bookingen.

Hvis holdet har en venteliste, får den første person pladsen og en mail.

Virker på en skærm i telefonbredde. Uden for omfang: refusioner, personale der annullerer for medlemmer. Byg dette, og tjek derefter hvert kriterium i preview, og fortæl mig hvilke der består.

Du kan også bede AI'en udkaste historier ud fra en grov idé og derefter redigere dem selv:

Her er min app-idé: [to eller tre sætninger]. Skriv user stories for en første version, grupperet efter brugertype, hver med 3 til 5 Given/When/Then-acceptkriterier. Markér hvilke der er nødvendige til lancering, og hvilke der kan vente.

Læs altid og rediger resultatet. AI'en kender ikke dine brugere; det gør du.

Acceptkriterierne fungerer også som din testplan. Når historien er bygget, gennemgår du hvert kriterium selv. Vores guide om test din app før lancering bygger videre på det her.

Hvor user stories passer sammen med andre dokumenter

Et produktkravsdokument beskriver hele produktet: problemet, brugerne, omfanget. User stories er de detaljerede dele inde i det. Se sådan skriver du en PRD med AI.
En fejlrapport beskriver noget, der er ødelagt i forhold til en historie, der allerede er bygget. Se sådan skriver du en god fejlrapport.
En MVP er det mindste sæt af historier, der leverer kerneværdien. Se hvad er en MVP.

Almindelige fejl

„Som bruger …“ For vagt. Navngiv den faktiske type bruger.
At springe „så“ over. Uden grunden kan du ikke træffe fornuftige afvejninger.
At skrive løsningen i stedet for behovet. „Jeg vil have en dropdown“ låser et design fast, før nogen har tænkt over det.
Kriterier, der ikke kan testes. „Nem“, „hurtig“ og „intuitiv“ er ønsker, ikke kriterier.
Historier, der egentlig er epics. „Administrér min konto“ er ti historier.
At skrive alle historier på forhånd. Skriv de næste få i detaljer; hold resten som éns-linjer, indtil du når til dem.

User stories i Mythex

I Mythex er Plan-tilstanden et godt sted at gøre en idé til historier: Agenten drøfter tilgangen, før den redigerer noget. Når en historie er klar, skift til Build og indsæt den, én historie pr. besked. Efter hver kan /test klikke sig igennem preview og tjekke flowet, og du kan rulle et svar tilbage med Gå tilbage til dette punkt, hvis det gik den gale vej. Se effektive prompts i dokumentationen og vores guide om at skrive prompts til AI-app-builders.

Tjekliste for user stories

Navngiver en bestemt type bruger
Beskriver et behov, ikke et design
Indeholder en reel „så“-grund
Har tre til seks testbare acceptkriterier
Dækker mindst én edge case eller fejl
Angiver hvad der er uden for omfang
Lille nok til at bygge og teste på ét forløb
Kriterier kontrolleret efter bygning, ét ad gangen

Spørgsmål

Hvad er formatet for en user story?

Den almindelige skabelon er: Som [type bruger] vil jeg [mål], så [grund]. Efter den kommer acceptkriterier, en kort liste af betingelser, der skal være opfyldt, før historien tæller som færdig.

Hvad er acceptkriterier?

Acceptkriterier er specifikke, testbare betingelser, der definerer, hvornår en user story er færdig. De skrives ofte i Given / When / Then-form: givet en startsituation, når brugeren gør noget, så sker et bestemt resultat.

Hvor stor bør en user story være?

Lille nok til at bygge og teste på én gang, og stadig værdifuld alene. Hvis en historie har mere end fem eller seks acceptkriterier, eller dækker flere skærme, så del den op efter brugerrolle, efter trin i flowet, eller først efter den enkle sag, med edge cases senere.

Er user stories nyttige, når man bygger med AI?

Ja. En user story med acceptkriterier ligner tæt på en ideel prompt: Den siger, hvem funktionen er til, hvad de har brug for, og præcis hvordan man tjekker, at det virker. Én historie pr. besked holder også AI-ændringerne små og nemme at teste.