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.
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”.
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.
En velkjent metode for å skrive gode brukerhistorier er å bruke det engelske akronymet INVEST:
Mange ting kan skje i en leveranse når forskjellige team i ulike miljø skal jobbe sammen. Men la meg nevne noen eksempler.
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.
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.
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.
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.
Jeg foreslår du starter med tre ting;
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.
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.
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!