Sådan skriver du user stories som udviklerne forstår
En user story beskriver et behov fra brugerens perspektiv, ikke en teknisk løsning. Som kunde skriver du den i formatet som-en-rolle-vil-jeg-mål-så-at-nytte og supplerer med acceptkriterier der gør den testbar. Hold storyen lille og fokuseret på hvad, ikke hvordan. De typiske faldgruber er for store stories og stories der allerede låser løsningen fast for udviklerne.
Som kunde er user stories ofte dit vigtigste værktøj til at fortælle hvad du vil have, uden at du behøver at kunne kode. Men en dårlig story skaber flere problemer end den løser: Enten er den så vag at teamet gætter, eller også er den så detaljestyrende at den kvæler bedre løsninger. Denne guide viser hvordan du skriver stories som udviklerne faktisk forstår, med eksempler på hvad der virker og hvad der ikke gør.
Formatet: som-en-vil-jeg-så-at
Grundskabelonen for en user story ser sådan ud:
Som [rolle] vil jeg [mål] så at [nytte].
Tre dele, og alle er nødvendige. Rollen siger hvem behovet gælder. En førstegangsbesøgende og en administrator vil sjældent det samme. Målet er det personen vil opnå. Nytten, så-at-delen, forklarer hvorfor, og det er den der oftest bliver glemt og betyder mest. Nytten hjælper teamet med at forstå formålet, foreslå den rigtige løsning og veje storyen op imod andre.
Sammenlign en svag og en god story:
- Dårlig: “Brugeren skal kunne filtrere.” (Hvilken bruger? Filtrere hvad? Hvorfor?)
- God: “Som tilbagevendende kunde vil jeg kunne filtrere mine ordrer på dato så jeg hurtigt kan finde et tidligere køb jeg vil reklamere over.”
Den anden giver teamet alt hvad de har brug for til at bygge den rigtige ting, og til at komme med en smartere løsning end den du selv havde tænkt på.
Acceptkriterier gør storyen testbar
En story uden acceptkriterier er en holdning til hvad “færdig” betyder. Kriterierne er de konkrete betingelser der afgør om storyen er leveret, og de gør at alle ser det samme. De behøver ikke være tekniske. De beskriver hvad der skal gælde fra brugerens perspektiv.
For filtreringsstoryen ovenfor kan kriterierne være:
| Acceptkriterium | Hvorfor det er nødvendigt |
|---|---|
| Der kan filtreres på start- og slutdato | Definerer selve funktionen |
| Et tomt resultat viser en tydelig besked | Dækker hvad der sker når intet matcher |
| Filteret kan nulstilles | Indfanger et almindeligt, men let glemt behov |
Læg særlig vægt på grænsetilfældene: hvad der sker når noget er tomt, forkert eller uventet. Det er dér uklare stories plejer at slå revner bagefter.
Typiske faldgruber du bør undgå
Tre fejl går igen når kunder skriver stories.
For store stories. “Som kunde vil jeg kunne administrere hele min konto” er ikke en story, det er en hel funktion. Den kan hverken estimeres eller gøres færdig. Del den op: ændre oplysninger, skifte adgangskode, se ordrehistorik. Hver af dem er en lille story for sig som leverer værdi.
Løsningsstyrende stories. “Placer en blå knap øverst til højre der åbner en modal” fratager teamet chancen for at foreslå noget bedre. Du har bestemt hvordan før du har sagt hvad. Beskriv i stedet behovet, og overlad udformningen til dem der bygger.
Pseudotekniske ønskelister. En story skal udtrykke et forretningsbehov, ikke forsøge at lyde teknisk. At klæde behovet i tekniske termer du ikke helt har styr på, skaber bare misforståelser. Skriv i klart sprog om hvad brugeren vil. Det er din styrke som kunde, ikke en svaghed.
Et konkret eksempel på opdeling
Lad os sige at du vil have “booking” i din app. Som én enkelt story er den uhåndgribelig. Delt op i mindre dele bliver den mulig at bygge:
- Som kunde vil jeg se ledige tider så jeg ved hvornår jeg kan booke.
- Som kunde vil jeg vælge en tid og bekræfte så jeg sikrer mig min plads.
- Som kunde vil jeg få en bekræftelse så jeg ved at bookingen er gået igennem.
- Som kunde vil jeg kunne afbestille så jeg slipper for at ringe hvis noget ændrer sig.
Nu har hver del et tydeligt hvad og hvorfor, kan estimeres og testes hver for sig og kan desuden prioriteres. Måske er der ikke brug for afbestilling i den første version. Det er hele pointen: Små og tydelige stories giver dig både bedre udvikling og en skarpere prioritering.
At skrive gode stories hænger sammen med at stille krav uden teknisk baggrund i det hele taget. Vil du have hjælp til at komme i gang med en backlog til jeres projekt, så kontakt os.
Ofte stillede spørgsmål
Hvad er en user story?
En user story er en kort beskrivelse af noget en bruger vil kunne gøre, formuleret fra brugerens perspektiv. Den indfanger et behov og nytten ved det, ikke en teknisk specifikation. Formålet er at teamet skal forstå hvad der skal opnås og hvorfor, og derefter selv finde ud af hvordan. En story er et udgangspunkt for en samtale, ikke en færdig kontrakt.
Hvad betyder formatet som-en-vil-jeg-så-at?
Det er standardskabelonen: 'Som [rolle] vil jeg [mål] så at [nytte].' Rollen siger hvem behovet gælder, målet hvad personen vil opnå og nytten hvorfor det er noget værd. Så-at-delen er den vigtigste og oftest den der bliver glemt. Den forklarer formålet, og det hjælper teamet med at finde den rigtige løsning og prioritere de rigtige ting over for hinanden.
Hvad er acceptkriterier?
Acceptkriterier er de konkrete betingelser der skal være opfyldt før storyen tæller som færdig. De gør en ellers uklar story testbar: Alle kan se om kriterierne er opfyldt eller ej. Uden dem bliver 'færdig' en holdning. De behøver ikke være tekniske. De beskriver hvad der skal gælde set fra brugerens side, f.eks. hvad der sker når noget går galt.
Hvor stor bør en user story være?
Lille nok til at blive bygget og testet inden for en sprint, helst mindre. En typisk begynderfælde er stories der i virkeligheden er hele funktioner. De bliver umulige at estimere og at gøre færdige. Er storyen for stor, så del den op i flere mindre som hver for sig leverer værdi. Mange små og tydelige stories slår nogle få uhåndgribelige.
Skal kunden skrive hvordan noget skal bygges?
Nej. En typisk fælde er løsningsstyrende stories der allerede har bestemt teknikken eller brugerfladen, f.eks. 'placer en blå knap øverst til højre'. Så fratager du teamet muligheden for at foreslå en bedre løsning. Beskriv behovet og nytten, altså hvad og hvorfor, og overlad hvordan til dem der bygger. Undtagelsen er reelle krav som regler eller lovkrav, og de hører hjemme i kriterierne.