Formen og hva den er god til
En brukerhistorie har tre ledd: hvem, hva og hvorfor. Det tredje leddet er hele poenget. Det tvinger fram en begrunnelse, og begrunnelsen gjør det mulig å foreslå en annen løsning enn den som ble bedt om.
Som saksbehandler
vil jeg varsles når en sak nærmer seg lovpålagt frist
slik at jeg rekker å behandle den i tide.
Merk hva som ikke står der: ingenting om e-post, varselikoner eller innstillinger. Det er med vilje. Formen er i slekt med grunnregelen om å beskrive behovet, ikke løsningen.
Hvorfor de ikke holder alene
En brukerhistorie er en påminnelse om en samtale, ikke en spesifikasjon. I smidig utvikling fungerer det godt, fordi samtalen faktisk finner sted hver uke. I en anskaffelse finnes ikke den samtalen: leverandøren leser teksten, priser den og signerer.
Derfor må historien suppleres med akseptansekriterier som gjør den etterprøvbar. Historien sier hvorfor; kriteriene sier når det er oppfylt.
Som saksbehandler vil jeg varsles før fristen går ut, slik at jeg rekker å behandle saken.
Gitt at en sak har 10 virkedager igjen til fristen,
når arbeidsdagen starter,
så vises saken øverst i saksbehandlerens oppgaveliste og telles i fristoversikten.
Gitt at saken er satt på vent i påvente av tilleggsopplysninger,
når fristen beregnes,
så stopper fristen å løpe fra det tidspunktet forespørselen ble sendt.
Når metoden passer
- I tidlig fase. Historier er raske å skrive og lette å sortere, og de holder samtalen på behov framfor løsning.
- Når mange skal bidra. Formen er lav terskel — fagfolk uten kravbakgrunn klarer den på ti minutter.
- Ved smidig leveranse etter kontraktsinngåelse. Da er formen den samme som leverandørens team jobber i.
Når den ikke er verdt bryet
- For ikke-funksjonelle krav. «Som bruker vil jeg at systemet skal være sikkert» er en tom setning. Kvalitetskrav skrives som krav med tall. Se kapittel 8.
- Som eneste form i konkurransegrunnlaget. 200 historier uten kriterier gir tilbud som ikke kan sammenlignes, fordi hver leverandør tolker sitt.
- Når det ikke finnes en reell bruker. «Som system vil jeg...» er et tegn på at du beskriver en teknisk oppgave. Skriv den som et vanlig krav.
Bruk historier til å samle inn og prioritere, og skriv dem om til nummererte krav med akseptansekriterier før utsendelse. Behold historien som begrunnelsesfelt på kravet — da har du «hvorfor» tilgjengelig når noen om to år spør om kravet fortsatt gjelder.
Vanlige feil
- «Slik at»-leddet fylles med fyll. «...slik at jeg kan varsles» er sirkulært. Er begrunnelsen vanskelig å skrive, er det ofte fordi behovet ikke er reelt.
- Historier uten eier. Se hvert krav trenger en eier.
- Løsningen smuglet inn i «vil jeg». «Vil jeg ha en nedtrekksmeny» er ikke et behov.
- Historier telles som krav i evalueringen. De er ikke like store, og de er ikke like bindende.