Brukerhistorier i Scrum: Alt du trenger å vite

Målet er klart: Du ønsker å utvikle et produkt som gir høy merverdi for kundene. Du vil oppnå et resultat som teammedlemmene og interessentene er fornøyde med. Men hvordan når du dette målet? Hvordan kan du oppfylle alle kravene til et produkt i små, grundige trinn? 

I Agile har brukerhistorier vist seg å være et effektivt verktøy for dette. De tar deg steg for steg fra den første ideen til et salgsklart produkt. Jeg vil vise deg hva brukerhistorier er, hvordan du lager dem og hvordan du kan dra nytte av dem.

Definisjonen av brukerhistorier i Agile beskriver kravene til et produkt sett fra brukerens synspunkt. Brukerhistorier forteller med andre ord hvilke egenskaper og funksjoner et produkt bør ha. Dette gjør dem til et sentralt verktøy for å diskutere og validere brukernes behov og jobbe med implementeringen av dem med en felles forståelse. 

Brukerhistorier er et universelt språk som teammedlemmer, interessenter og kunder forstår og snakker. I praksis betyr dette at du kan bruke brukerhistorier til å utvikle en forståelse av produktet som kunden ønsker, og som gir lite rom for misforståelser. 

Flere brukerhistorier utgjør til sammen et brukstilfelle. Brukerhistorier har sin opprinnelse i Agile Software Development.

Brukerhistorier beskriver kravene og ønskene til et prosjektresultat som skal skapes fra kundens eller brukerens perspektiv. Agile brukerhistorier har denne grunnleggende strukturen:

WHO (rolle), ønsker HVA (mål/ønske) HVORFOR (merverdi)?

La oss se nærmere på de enkelte komponentene i brukerhistoriene:

HVEM (BRUKER)

Du fyller ut WER-plassholderen med kunden din eller en typisk representant for målgruppen din. Hvor detaljert du beskriver WHO i brukerhistorien, avhenger av selve brukerhistorien og fremdriften i prosjektet. Vær derfor detaljert nok til å skape en meningsfull brukerhistorie.

HVA (FUNKSJON)

Det er her du plasserer brukerens ønsker. Du kan spørre deg selv hva brukeren forventer eller har behov for. Hvis produktet ditt fortsatt er i en tidlig utviklingsfase, kan du ut fra dine erfaringer formulere antagelser om hvilke funksjoner brukeren forventer. Hvis du allerede har et lignende produkt på markedet, kan du også utlede de ønskede funksjonene fra tilbakemeldingene på dette produktet.

HVORFOR (MERVERDI)

Først når merverdien viser hvorfor en funksjon er viktig for brukeren. HVORFOR gir deg derfor en ærlig refleksjon over hvor godt du kjenner en kundes behov. For: Det er enkelt å inkludere et krav i en brukerhistorie – for eksempel fordi kunden uttrykker et ønske om det. Men først når du forstår hvorfor kunden trenger dette, har du konteksten for å implementere kravet. Først da kan du stille spørsmål ved om kundens forslag/ønske effektivt tilfredsstiller deres faktiske behov – eller om det kanskje finnes en smartere måte. La oss se på et eksempel: 

Kunden ønsker seg en regncape til sykling. Derfor kan du nå inkludere kravet “regnkappe”. Eller du kan spørre kunden hvorfor han trenger en regncape. La oss si at kunden svarer “Fordi jeg ikke vil bli våt”. 

Det betyr at du ikke nødvendigvis trenger å levere en regnkappe. Du kan også levere en sykkel med integrert tak. Det avgjørende er at kundens behov eller problem blir løst – nemlig å ikke bli våt. Jo bedre du forstår «hvorfor», desto bedre kan du utforme brukerhistorien din.

Hva er brukerhistorier i Agile (eksempel)?

Du kjenner nå de enkelte komponentene i Agile-brukerhistorier. Et eksempel på en Agile-brukerhistorie kan se slik ut: 

Som KUNDE Jeg vil gjerne ET SIKKERT PASSORD***,*** SLIK AT KUNDEDATAENE MINE ER BESKYTTET.

Her er “KUNDE” brukeren, “ET SIKKERT PASSORD” funksjonen og “SLIK AT KUNDEDATAENE MINE ER BESKYTTET” merverdi. 

Når du arbeider med brukerhistorier i Scrum, legger du til akseptansekriterier. Akseptkriterier beskriver de tekniske kravene som brukerhistoriene må oppfylle når de aksepteres. Med andre ord: Akseptkriterier er de kravene du trenger for at en brukerhistorie skal skape verdi.

Betydningen av Agile-brukerhistorier i backloggen kan være mer differensiert. Fordi: I backlogs kan brukerhistorier ikke bare beskrive krav, men også representere en spesiell hierarkitype. Det finnes disse 3 hierarkitypene:

Epos: Epics er bredt definerte funksjonsområder i et produkt der det konkrete omfanget fortsatt kan være uklart.

Funksjoner: Funksjoner er spesifikke ytelsesegenskaper i et epos.

Historier: Historier er tekniske Agile brukerhistorier og brukerhistorier innenfor en funksjon.

Du kan implementere disse hierarkitypene i løpet av en sprint. De skaper en konkret fordel for brukeren. 

For å kunne skrive gode brukerhistorier i smidig prosjektledelse er det avgjørende med grundige diskusjoner med alle interessenter. Disse skal gi deg en omfattende forståelse av målgruppen og produktet som skal skapes. Ut fra dette kan du for eksempel utlede personas. 

I tillegg er den såkalte INVEST-kriterierfor å skape en overbevisende brukerhistorie:

Uavhengig: En brukerhistorie skal være uavhengig av andre brukerhistorier. Det betyr at implementeringen av en story ikke må forutsette at en annen story er implementert på forhånd. Dette har den fordelen at du når som helst kan prioritere brukerhistorier eller fjerne dem fra backloggen. 

La oss ta en ny titt på sykkeleksemplet. La oss si at du bestemmer deg for å installere et lite tak over sykkelsadelen i stedet for en regnkappe, slik at kunden ikke blir våt lenger. Det ville være en brukerhistorie. Men nå innser du at du først må utvikle en mer stabil sadel som taket kan festes til. Det er en annen brukerhistorie. Begge historiene bygger på hverandre. Det er nettopp dette du bør unngå.

Selvfølgelig er det noen ganger uunngåelig at du må gjøre en brukerhistorie før en annen. Men som hovedregel bør du unngå brukerhistorier der du først må implementere 20 andre brukerhistorier.

Kan forhandles: Å skrive brukerhistorier kan noen ganger ta ganske lang tid – men de bør ikke være hugget i stein etterpå. Det betyr: Produktansvarlig Interessenter og utviklere bør alltid diskutere og forbedre en brukerhistorie sammen. 

Verdifull: Resultatet av brukerhistorier i smidig prosjektledelse må ha en merverdi for kunden.

Anslått: En overbevisende brukerhistorie gjør det mulig for utviklingsteamet å anslå hvor mye arbeid som kreves for å implementere den.

Liten: En brukerhistorie bør være så “liten” at den kan realiseres i løpet av én sprint.

Kan testes: Brukerhistorier i Scrum skal kunne testes. Det er den eneste måten å sjekke om de virkelig kan implementeres i praksis.

Hvis du ikke er kjent med å skrive brukerhistorier i Agile, kan det virke som ekstraarbeid. Brukerhistorier gir imidlertid teamene en viktig kontekst for oppgavene deres, og tydeliggjør viktigheten av hver enkelt oppgave.

I bunn og grunn er det slik du drar nytte av brukerhistorier:

Brukerfokus: Brukerhistorier er som en problemorientert huskeliste. Teamet ditt kan bruke dem til å holde oversikt over oppgavene sine og vite nøyaktig hvordan de skal oppfylle brukernes behov.

Helhetlig samarbeid: Brukerhistorier viser alle involverte på et øyeblikk hvor det bærer hen. På denne måten kan alle dra lasset sammen og bestemme seg igjen og igjen for hvordan brukeren skal få spesielt høy merverdi. 

Kreative løsninger: Opprette brukerhistorier i Agile-programvareutvikling kreative resultater . Fordi: De får teamene til å tenke kritisk på hva som er den beste løsningen for sluttproduktet.

Konsekvent suksess: Hver brukerhistorie er en liten utfordring. Teamene kan derfor feire en liten suksess etter hver historie. Dette motiverer gjennom hele utviklingsprosessen.

Brukerhistorier er et viktig verktøy i arbeidet med smidige team. De viser deg igjen og igjen i detalj for hvem du utvikler hva og hvorfor. Dette bidrar ikke bare til å skape et produkt av høy kvalitet som er skreddersydd for målgruppen, men også til å holde teamet motivert gjennom hele prosessen. 

For at du skal lykkes på dette makronivået av agilt arbeid, må hele organisasjonen tenke og fungere agilt. For å støtte deg og din organisasjon i dette arbeidet har vi samarbeidet med anerkjente eksperter for å skape Prosjekt Scagile utformet. Den viser deg i ulike webinarer hvordan du går frem for å gjennomføre en smidig transformasjon på riktig måte. Opplæringen er gratis. Ta gjerne en titt!

Hvis du ønsker mer varierte spørsmål til retrospeksjonene dine, kan du ta en titt på innlegget vårt om dette: 54 nye retrospektive metoder for nybegynnere og profesjonelle (med blant annet Mario Kart Retro, Marathon Retro og Elon Musk Retro).

En av de beste metodene for å utvikle et agilt tankesett hos teammedlemmer på en bærekraftig måte er forresten å implementere en agil helsesjekk. Vår gratis byggesett Team-Health Check kan hjelpe deg med å stille de riktige spørsmålene – bare klikk deg gjennom.