Slik skriver du user stories som utviklerne forstår
En user story beskriver et behov fra brukerens perspektiv, ikke en teknisk løsning. Som kunde skriver du den i formatet «Som [rolle] vil jeg [mål] slik at [nytte]» og supplerer den med akseptansekriterier som gjør den testbar. Hold historien liten og fokusert på hva, ikke hvordan. De vanligste fellene er for store historier og historier som låser løsningen på forhånd.
For deg som kunde er user stories (brukerhistorier) ofte det viktigste verktøyet for å fortelle hva du vil ha, uten å måtte kunne kode. Men en dårlig historie skaper flere problemer enn den løser: Den er enten så vag at teamet gjetter, eller så detaljstyrende at den kveler bedre løsninger. Denne guiden viser hvordan du skriver user stories som utviklerne faktisk forstår, med eksempler på hva som fungerer, og hva som ikke gjør det.
Formatet: «Som … vil jeg … slik at»
Grunnmalen for en user story ser slik ut:
Som [rolle] vil jeg [mål] slik at [nytte].
Tre deler, alle nødvendige. Rollen sier hvem behovet gjelder: En førstegangsbesøkende og en administrator ønsker sjelden det samme. Målet er det personen ønsker å oppnå. Nytten, «slik at»-delen, forklarer hvorfor, og det er den som oftest blir glemt, og som betyr mest. Nytten hjelper teamet med å forstå formålet, foreslå riktig løsning og vurdere historien opp mot andre.
Sammenlign en svak og en god user story:
- Dårlig: «Brukeren skal kunne filtrere.» (Hvilken bruker? Filtrere hva? Hvorfor?)
- Bra: «Som tilbakevendende kunde vil jeg filtrere ordrene mine på dato slik at jeg raskt finner et tidligere kjøp jeg vil reklamere på.»
Den andre gir teamet alt de trenger for å bygge det riktige, og for å komme med en smartere løsning enn du selv hadde tenkt på.
Akseptansekriterier gjør historien testbar
En user story uten akseptansekriterier er en mening om hva «ferdig» betyr. Kriteriene er de konkrete vilkårene som avgjør om historien er levert, og de gjør at alle ser det samme. De trenger ikke å være tekniske; de beskriver hva som skal gjelde fra brukerens perspektiv.
For filtreringshistorien ovenfor kan kriteriene være:
| Akseptansekriterium | Hvorfor det trengs |
|---|---|
| Ordrene kan filtreres på start- og sluttdato | Definerer selve funksjonen |
| Tomt resultat viser en tydelig melding | Dekker hva som skjer når ingenting matcher |
| Filteret kan nullstilles | Fanger et vanlig, men lett glemt behov |
Legg ekstra vekt på grensetilfellene: hva som skjer når noe er tomt, feil eller uventet. Det er der uklare historier pleier å slå sprekker.
Vanlige feller å unngå
Tre feil går igjen når kunder skriver user stories.
For store historier. «Som kunde vil jeg administrere hele kontoen min» er ingen user story, men en hel funksjon. Den er umulig både å estimere og å bli ferdig med. Del den opp: endre opplysninger, bytte passord, se ordrehistorikk. Hver av dem blir en egen liten historie som leverer verdi.
Løsningsstyrende historier. «Legg en blå knapp øverst til høyre som åpner et modalvindu» fratar teamet sjansen til å foreslå noe bedre. Du har bestemt hvordan før du har sagt hva. Beskriv heller behovet og overlat utformingen til dem som bygger.
Pseudotekniske ønskelister. En user story skal uttrykke et forretningsbehov, ikke prøve å høres teknisk ut. Å kle behovet i tekniske begreper du ikke helt behersker, skaper bare misforståelser. Skriv i klarspråk om hva brukeren vil. Det er styrken din som kunde, ikke en svakhet.
Et konkret eksempel på oppdeling
Si at du vil ha «booking» i appen din. Som én eneste historie er den uhåndterlig. Brutt ned i mindre deler blir den mulig å bygge:
- Som kunde vil jeg se ledige tider slik at jeg vet når jeg kan booke.
- Som kunde vil jeg velge en tid og bekrefte slik at jeg sikrer meg plassen.
- Som kunde vil jeg få en bekreftelse slik at jeg vet at bookingen gikk gjennom.
- Som kunde vil jeg ha mulighet til å avbestille slik at jeg slipper å ringe hvis noe endres.
Nå har hver del et tydelig hva og hvorfor, den kan estimeres og testes for seg, og den kan dessuten prioriteres: Kanskje trengs ikke avbestilling i første versjon. Det er hele poenget: Små, tydelige user stories gir deg både bedre utvikling og skarpere prioritering.
Å skrive gode user stories henger sammen med kravstilling uten teknisk bakgrunn generelt. Vil dere ha hjelp til å komme i gang med en backlog for prosjektet, ta kontakt.
Ofte stilte spørsmål
Hva er en user story?
En user story er en kort beskrivelse av noe en bruker ønsker å kunne gjøre, formulert fra brukerens perspektiv. Den fanger et behov og nytten av det, ikke en teknisk spesifikasjon. Formålet er at teamet skal forstå hva som skal oppnås og hvorfor, og deretter selv få løse hvordan. En user story er et utgangspunkt for samtale, ikke en ferdig kontrakt.
Hva betyr formatet «Som … vil jeg … slik at»?
Det er standardmalen: «Som [rolle] vil jeg [mål] slik at [nytte].» Rollen sier hvem behovet gjelder, målet hva personen ønsker å oppnå og nytten hvorfor det er verdt noe. Delen med «slik at» er viktigst og oftest den som blir glemt. Den forklarer formålet, noe som hjelper teamet med å finne riktig løsning og veie oppgavene riktig opp mot hverandre.
Hva er akseptansekriterier?
Akseptansekriterier er de konkrete vilkårene som må være oppfylt for at historien skal regnes som ferdig. De gjør en ellers vag user story testbar: Alle kan se om kriteriene er oppfylt eller ikke. Uten dem blir «ferdig» en smakssak. De trenger ikke å være tekniske; de beskriver hva som skal gjelde fra brukerens ståsted, for eksempel hva som skjer når noe går galt.
Hvor stor bør en user story være?
Liten nok til å bygges og testes innenfor én sprint, helst mindre. En vanlig nybegynnerfelle er historier som egentlig er hele funksjoner. De blir umulige å estimere og å bli ferdig med. Er historien for stor, del den opp i flere mindre som hver for seg leverer noe av verdi. Mange små, tydelige historier slår noen få uoversiktlige.
Skal kunden skrive hvordan noe skal bygges?
Nei. En vanlig felle er løsningsstyrende historier som allerede har bestemt teknologien eller grensesnittet, for eksempel «legg en blå knapp øverst til høyre». Da fratar du teamet muligheten til å foreslå en bedre løsning. Beskriv behovet og nytten, altså hva og hvorfor, og overlat hvordan-spørsmålet til dem som bygger. Unntaket er reelle krav, som regler eller lovkrav, og de hører hjemme i kriteriene.