Du som jobber med produkt, - og tjenesteutvikling, har sikkert opplevd at brukerhistorier ikke alltid fungerer som ønsket? Du har kanskje noen ganger lurt på hvorfor det ikke ble så lett for leveranseteamet å skissere eller utvikle en løsning, som skulle ivareta det behovet beskrevet i brukerhistorien? Kanskje opplevde du at utfordringen oppstod da funksjonaliteten skulle testes?
Nei, det er rett og slett ikke alltid lett å jobbe utfra en kort setning som beskriver en bruker i “action”. Og ja, det finnes mange grunner for at brukerhistorier feiler. Heldigvis erfarer jeg at det foreligger mange hjelpemidler og metoder for å unngå mulige «skjær i sjøen».
I dette blogginnlegget presenterer jeg noen av de vanligste utfordringene med brukerhistorier, og hvordan du kan unngå dem.
Hva er brukerhistorier?
Brukerhistorier er korte og enkle beskrivelser av hva en sluttbruker ønsker å oppnå ved å bruke et produkt eller en tjeneste. Funksjonaliteten beskrives i brukerens perspektiv og lar utviklingsteamet finne en teknisk løsning. Brukerhistoriene kan betraktes som byggeklosser som sammen danner en epic, et hovedelement i programvaren, som i sin tur utformer et tema eller en hovedfunksjon.
Brukerhistorier svarer på “Hvem”, “Hva”- og “Hvorfor”-spørsmål og følger et fast format, vanligvis: «Som en [rolle], ønsker jeg [noe/å gjøre noe], slik at jeg [oppnår en gevinst]». Et eksempel på en brukerhistorie kan være, “Som konsulent i Metier ønsker jeg å dele mine erfaringer slik at jeg bidrar til å øke kunnskapen om digitalisering”.
Historien bak brukerhistoriene
Ideen om å fortelle hvordan et system fungerer gjennom korte historier fra brukerens ståsted oppstod på 90-tallet da IT-prosjektteam hadde (for stort) fokus på systemer og ikke nok på deres sluttbrukere. Systemkravene var knyttet til omfattende dokumentasjon utarbeidet typisk i fossefall utviklingsprosjekter, mens med sin enkle og overordnede oppbygging egner brukerhistoriene seg for korte utviklingsiterasjoner som er sentrale i smidig metoder. I tillegg er det et godt utgangspunkt for å starte opp en dialog mellom produktteamet og utviklingsteamet.
Produktteamet eller produkteieren har ansvar for å skrive brukerhistoriene, prioritere dem i backloggen, og sørge for at de står klare når utviklingsteamet skal jobbe videre med dem. Det vil si at brukerhistoriene skal tilfredsstille kriterier satt i «Definition of Ready» (DoR), dette for å sikre at stafettpinnen knirkefritt går fra et team til et annet.
5 grunner til å lage brukerhistorier
- Brukerhistorier gjør det lettere å forstå funksjonene i produktet eller tjenesten som skal leveres.
- Fordi brukerhistoriene tar utgangspunktet i brukeren blir funksjonene som skal utvikles brukersentrert. Disse vil da med større sannsynlighet løse et reelt problem og dekke et ekte behov hos brukeren.
- Brukerhistorier bidrar til å øke produktiviteten i utviklingsteamet, gjennom styrket motivasjon fordi de ofte fører til mindre arbeidsoppgaver som passer innenfor en iterasjon. Når en historie blir fullført, får teamet fornyet energi før en ny brukerhistorie hentes fra backlog.
- Formatet til brukerhistoriene – de er kortfattet, tilstrekkelig og personifisert – gir rom for at utviklingsteamet kan komme med innovative ideer og være kreative i sin leveranse.
- Brukerhistorier lar teammedlemmer samarbeide for å bestemme hvordan de best kan tilfredsstille sluttbrukernes behov og levere verdi.
Hvordan får du gode brukerhistorier?
En velkjent metode for å skrive gode brukerhistorier er å bruke det engelske akronymet INVEST:
- Independent (Uavhengig): brukerhistoriene bør være selvstendige slik at de kan legges ut i drift idet de er ferdig testet, uten å være avhengig av hverandre.
- Negotiable (Forhandlingsbar): En brukshistorie skal ikke skrives som en kontrakt. Den skal heller beskrive essensen av brukerens behov, og invitere produktteamet og utviklingsteamet til en konstruktiv diskusjon. Produktteamet kjenner til brukerens motiver og verdien som funksjonen skal frembringe, og utviklingsteamet vet hvordan man skal få til en løsning.
- Valuable (Verdifull): gevinsten som funksjonaliteten skal realisere skal komme frem i brukerhistorien.
- Estimable (Estimerbar): Brukerhistorier må estimeres slik at de kan prioriteres riktig og planlegges inn i iterasjoner. For å få til det må brukerhistoriene gi utviklingsteamet nok detaljer til å anslå størrelsen.
- Small (Liten): En brukerhistorie er et stykke arbeid som skal levere en verdifull enhet av programvare. Jo mindre arbeidsmengde historien krever, desto mer sannsynlig er det at brukerens verdi blir levert når iterasjonen tar slutt.
- Testable (Testbar): En brukerhistorie bør ha akseptansekriterier som kan brukes for å verifisere at funksjonen faktisk er levert. Akseptansekriteriene skal være objektive, og enkle å måle og teste.
Så hva kan gå feil?
Mange ting kan skje i en leveranse når forskjellige team i ulike miljø skal jobbe sammen. Men la meg nevne noen eksempler.
Manglende kommunikasjon
Hensikten med å lage brukerhistorier er å legge til rette for en samtale mellom produktteamet og utviklingsteamet. Husk at god kommunikasjon er en forutsetning for å lykkes med smidig leveranser. Selv om produktteamet er ansvarlig for å utarbeide gode brukerhistorier skal de involvere utviklingsteamet, og dette samarbeidet bidrar til slutt til at alle har en omforent forståelse av det som skal leveres.
Brukerhistorier er ikke klare
Noen brukerhistorier er for store for å bli levert i en iterasjon. Noen er for vage og trenger mer “kjøtt på beina” før de kan overrekes til utviklingsteamet. Andre kan derimot inneholde irrelevante detaljer som helst bør fjernes før en teknisk løsning skisses og bygges. Noen ganger er brukeren ikke spesifisert godt nok slik at det er utfordrende å oppnå en optimal leveranse. Til slutt, når det kommer til brukergrensesnittet og brukerinteraksjon, er brukerhistorier mindre egnet enn f.eks. skisser, mock-ups, scenarier, historiekart, osv. Disse verktøy kan med fordel brukes for å gi et mer komplett bilde av brukerens ståsted og behov.
Mangelfulle akseptansekriteria
Når produktteamet har sitt søkelys på å beskrive brukerhistorier, blir akseptansekriteriene noen ganger uteglemt og ikke levert til utviklingsteamet. Av og til passer ikke helt akseptansekriteriene i forhold til brukerhistoriene og verifiseringen av leveransen blir da utfordrende.
Brukerhistorien beskriver løsningen som skal leveres
Produktteamet kan noen ganger se for seg en løsning for å dekke behovet til brukeren og formulere den i brukerhistorien. Dette er uheldig da det er utviklingsteamet som har riktig kompetanse for å komme til en god løsning.
Hva kan du gjøre?
Jeg foreslår du starter med tre ting;
1. Legg til rette for en god organisasjonskultur og et trygt miljø for dialog
Som oftest i leveranser som involverer mange personer er god kommunikasjon nøkkelen til suksess. Det betyr konkret at det ikke skal være en høy terskel for å stille spørsmål, ytre betraktninger eller fremme nye idéer. Målet er å levere mest verdi for brukeren og dette krever at alle involverte i jobben forstår brukerhistorien inn og ut. Hvis folk jobber virtuelt i din organisasjon, planlegg noen fysiske sammenkomster og arranger teambyggingsaktiviteter, som gjør det lettere for de ulike miljøene til å bli til ett.
2. Bli kjent med brukerne
Det finnes mest sannsynligvis flere typer brukere til produktet eller tjenesten som skal utvikles, ikke bare den ene "brukeren". Derfor er det klokt å starte med å kartlegge hvem brukerne er og deretter å identifisere tre til fire arketyper, såkalte persona. Disse er fiktive karakterer som beskrives med navn og bilde, relevante egenskaper, aktiviteter, prioriteter, atferd, holdninger, motivasjoner, forventninger, mål, med mer.
3. Bruk et produkt canvas
Verktøyet gir en kondensert, sammenhengende og konsis oversikt over viktig og nyttig informasjon om produktet og tjenesten som skal utvikles. Det hjelper å bygge og opprettholde en felles forståelse på tvers av team, og bidrar til en bedre håndtering av backlogg, planlegging av utgivelser og ikke minst til å levere mer verdi til brukerne.
Lykke til!
