Så skriver du user stories som utvecklarna förstår
En user story beskriver ett behov ur användarens perspektiv, inte en teknisk lösning. Som beställare skriver du den i formatet som-en-roll-vill-jag-mål-så-att-nytta och kompletterar med acceptanskriterier som gör den testbar. Håll storyn liten och fokuserad på vad, inte hur. De vanligaste fällorna är för stora stories och sådana som redan låser lösningen åt utvecklarna.
Som beställare är user stories ofta ditt främsta verktyg för att tala om vad du vill ha – utan att behöva kunna kod. Men en dålig story ställer till mer än den löser: den är antingen så vag att teamet gissar, eller så detaljstyrande att den kväver bättre lösningar. Den här guiden visar hur du skriver stories som utvecklarna faktiskt förstår, med exempel på vad som fungerar och inte.
Formatet: som-en-vill-jag-så-att
Grundmallen för en user story ser ut så här:
Som [roll] vill jag [mål] så att [nytta].
Tre delar, alla nödvändiga. Rollen säger vem behovet gäller – en förstagångsbesökare och en administratör vill sällan samma sak. Målet är vad personen vill uppnå. Nyttan, så-att-delen, förklarar varför – och det är den som oftast glöms och som betyder mest. Nyttan hjälper teamet att förstå syftet, föreslå rätt lösning och väga storyn mot andra.
Jämför en svag och en bra story:
- Dålig: “Användaren ska kunna filtrera.” (Vilken användare? Filtrera vad? Varför?)
- Bra: “Som återkommande kund vill jag kunna filtrera mina ordrar på datum, så att jag snabbt hittar ett tidigare köp jag vill reklamera.”
Den andra ger teamet allt de behöver för att bygga rätt sak – och för att komma med en smartare lösning än du själv tänkt.
Acceptanskriterier gör storyn testbar
En story utan acceptanskriterier är en åsikt om vad “klart” betyder. Kriterierna är de konkreta villkor som avgör om storyn är levererad, och de gör att alla kan se samma sak. De behöver inte vara tekniska – de beskriver vad som ska gälla ur användarens perspektiv.
För filtreringsstoryn ovan kan kriterierna vara:
| Acceptanskriterium | Varför det behövs |
|---|---|
| Går att filtrera på start- och slutdatum | Definierar själva funktionen |
| Tomt resultat visar ett tydligt meddelande | Täcker vad som händer när inget matchar |
| Filtret går att nollställa | Fångar ett vanligt men lätt glömt behov |
Lägg särskilt kraft på kanterna – vad som händer när något är tomt, fel eller oväntat. Det är där oklara stories brukar spricka i efterhand.
Vanliga fällor att undvika
Tre misstag återkommer när beställare skriver stories.
För stora stories. “Som kund vill jag kunna hantera hela mitt konto” är ingen story, det är en hel funktion. Den går varken att uppskatta eller bli klar med. Dela upp den: ändra uppgifter, byt lösenord, se orderhistorik – var och en en egen liten story som levererar värde.
Lösningsstyrande stories. “Lägg en blå knapp uppe till höger som öppnar en modal” tar ifrån teamet chansen att föreslå något bättre. Du har bestämt hur innan du sagt vad. Beskriv behovet i stället och lämna utformningen till dem som bygger.
Pseudotekniska önskelistor. En story ska uttrycka ett verksamhetsbehov, inte försöka låta teknisk. Att klä behovet i tekniska termer du inte helt äger skapar bara missförstånd. Skriv i klarspråk om vad användaren vill – det är din styrka som beställare, inte en svaghet.
Ett konkret exempel på uppdelning
Säg att du vill ha “bokning” i din app. Som en enda story är den ogripbar. Bruten i mindre delar blir den byggbar:
- Som kund vill jag se lediga tider, så att jag vet när jag kan boka.
- Som kund vill jag välja en tid och bekräfta, så att jag säkrar min plats.
- Som kund vill jag få en bekräftelse, så att jag vet att bokningen gick igenom.
- Som kund vill jag kunna avboka, så att jag slipper ringa om något ändras.
Nu har varje del ett tydligt vad och varför, kan uppskattas och testas var för sig, och kan dessutom prioriteras – kanske behövs avbokning inte i första versionen. Det är hela poängen: små, tydliga stories ger dig både bättre bygge och skarpare prioritering.
Att skriva stories väl hänger ihop med att kravställa utan teknisk bakgrund i stort. Vill du ha stöd att komma igång med en backlog för ert projekt, hör av dig.
Vanliga frågor
Vad är en user story?
En user story är en kort beskrivning av något en användare vill kunna göra, formulerad ur användarens perspektiv. Den fångar ett behov och nyttan med det, inte en teknisk specifikation. Syftet är att teamet ska förstå vad som ska uppnås och varför, och sedan själva få lösa hur. En story är en utgångspunkt för samtal, inte ett färdigt kontrakt.
Vad betyder formatet som-en-vill-jag-så-att?
Det är standardmallen: 'Som [roll] vill jag [mål] så att [nytta].' Rollen säger vem behovet gäller, målet vad personen vill uppnå och nyttan varför det är värt något. Så-att-delen är viktigast och oftast den som glöms – den förklarar syftet, vilket hjälper teamet att hitta rätt lösning och prioritera rätt saker mot varandra.
Vad är acceptanskriterier?
Acceptanskriterier är de konkreta villkor som måste vara uppfyllda för att storyn ska räknas som klar. De gör en annars luddig story testbar: alla kan se om kriterierna är mötta eller inte. Utan dem blir 'klart' en åsikt. De behöver inte vara tekniska – de beskriver vad som ska gälla ur användarens synvinkel, till exempel vad som händer när något går fel.
Hur stor bör en user story vara?
Liten nog att byggas och testas inom en sprint, helst mindre. En vanlig nybörjarfälla är stories som egentligen är hela funktioner – de blir omöjliga att uppskatta och att bli klar med. Är storyn för stor, dela upp den i flera mindre som var för sig levererar något värde. Många små, tydliga stories slår ett fåtal svårgripbara.
Ska beställaren skriva hur något ska byggas?
Nej. En vanlig fälla är lösningsstyrande stories som redan bestämt tekniken eller gränssnittet, till exempel 'lägg en blå knapp uppe till höger'. Då tar du ifrån teamet möjligheten att föreslå en bättre lösning. Beskriv behovet och nyttan – vad och varför – och lämna hur till dem som bygger. Undantaget är verkliga krav, som regler eller lagkrav, vilka hör hemma i kriterierna.