En brukerhistorie er en naturlig beskrivelse av funksjonen til en programvare sett fra et brukerperspektiv. Det brukes som et verktøy i programvareutvikling for å utforme krav til hvordan programvaren skal fungere fra et brukerperspektiv. De kan for eksempel skrives på papir, Post-it-lapper eller digital programvare. Avhengig av prosjektet kan brukerhistorier skrives av ulike interessenter som en klient, bruker, leder eller et utviklingsteam.
Brukerhistorier er en type grenseobjekt. De fasiliterer meningssøk (engelsk: sensemaking) og kommunkasjon, og kan hjelpe utviklerteamet med å dokumentere sin forståelse av systemet og dets kontekst.
Prinsipp Brukerhistorier skrives enten av eller for brukere eller kunder for å påvirke funksjonaliteten til systemet som utvikles. I noen lag er den produktansvarlige (eller produkteieren i Scrum) som er primært ansvarlig for å formulere brukerhistorier og organisere dem i en produktkø. I andre lag kan hvem som helst skrive en brukerhistorie. Brukerhistorier kan utvikles gjennom diskusjon med interessenter være basert på personas eller bare funnet på etter eget forgodtbefinnende.
Typiske maler Brukerhistorier kan lages i flere ulike formater.
Det vanligste oppsettet er Connextra-malen (Connextra template) angitt nedenfor. Mike Cohn har foreslått at "slik at"-klausulen er valgfri, men fortsatt ofte er nyttig.
Som en <rolle> kan jeg <evne>, slik at <motta fordel>
Chris Matts foreslo at å "jakte på verdien" ("hunting the value") var det første steget i å levere programvare, og foreslo følgende alternative mal:
For å <motta fordel> som en <rolle>, kan jeg <mål/ønske>
En annen mal basert på de store h-ene (hvem, hva, hvortid, hvor, hvorfor) er:
Som <hvem> <når> <hvor>, vil jeg <hva> fordi <hvorfor>
Eksempler Screening-quiz (eposhistorie) "Som HR-leder vil jeg lage en screeningsquiz slik at jeg kan forstå om jeg vil sende mulige kandidater til fagleder".
Quiz-oversikt Som leder vil jeg bla gjennom mine eksisterende quizer, slik at jeg kan huske hva jeg har og finne ut om jeg kan gjenbruke eller bør oppdatere quizzen for den stillingen jeg trenger å fylle nå.
Begrenset sikkerhetskopiering Som bruker kan jeg angi hvilke mapper jeg ikke trenger å sikkerhetskopiere, slik at lagringsplassen ikke blir fylt opp med ting jeg ikke trenger.
Bruk En sentral del av mange smidige utviklingsmetoder, som for eksempel planlegging spillet i ekstrem programmering, er at brukerhistorier beskriver hva som kan bygges i programvareprosjektet. Brukerhistorier prioriteres av kunden (eller produkteieren i Scrum) for å indikere hvilke funksjoner som er viktigst for systemet, og vil deretter bli brutt ned til oppgaver og estimert av utviklerne. En måte å estimere på er via Scrum sin variant av Fibonacci-skalaen.
Når brukerhistorier skal implementeres bør utviklerne ha mulighet til å kommunisere med kunden om det. Korte historier kan være vanskelige å tolke, kan kreve litt bakgrunnskunnskap eller kravene kan ha endret seg siden historien ble skrevet.
Brukerhistorier kan utvides ved å legge til detaljer basert på samtaler med produkteieren. Dette kan omfatte notater, vedlegg og akseptkriterier.
Akseptansekriterier Mike Cohn definerer akseptkriterier som "notater om hva brukerhistorien må gjøre for at produkteieren skal akseptere det som komplett". Kriteriene definerer grensene for en brukerhistorie, og brukes til å bekrefte når en historie er fullført og fungerer som ønsket.
Den riktige mengden informasjon som skal inkluderes i akseptkriteriene varierer etter lag, program og prosjekt. Noen kan inkludere "forgjengerkriterier" som at "brukeren har allerede logget inn og har allerede redigert informasjonen sin en gang". Noen skriver akseptkriterier i det typisk smidige formatet "gitt-når-da". Andre bruker bare kulepunkter hentet fra krav opprinnelig samlet fra kunder eller interessenter.
For at en historie skal anses ferdig eller fullført må alle akseptkriterier være oppfylt.
Fordeler Det er ingen gode bevis på at bruk av brukerhistorier øker programvaresuksess eller utviklerproduktivitet. Brukerhistorier letter imidlertid sensemaking uten unødig problemstrukturering, hvilket er knyttet til suksess.
Begrensninger Begrensninger med brukerhistorier inkluderer:
Oppskaleringsproblem: Brukerhistorier skrevet på små fysiske lapper er vanskelige å vedlikeholde, vanskelig å skalere til store prosjekter og utfordrende for geografisk spredde lag. Vage, uformelle og ufullstendige: Brukerhistorier regnes som samtalestartere. Siden de er uformelle kan de åpne for mange ulike tolkninger. Gjennom å være korte oppgir de ikke alle detaljene som er nødvendige for å implementere en funksjon. Brukerhistorier er derfor upassende som basis for å inngå formelle avtaler eller skrive juridiske kontrakter. Mangel på Ikke-funksjonelle krav: Brukerhistorier inneholder sjelden detaljer om ytelse eller ikke-funksjonelle krav, hvilket medfører at ikke-funksjonelle tester (for eksempel av responstid) kan bli oversett. Representerer ikke nødvendigvis hvordan teknologien må bygges: Siden brukerhistorier ofte skrives er vinklet fra et forretningsperspektiv kan det hende at det teknisk teamet som begynner å implementere finner at tekniske begrensninger krever innsats som er mye bredere enn skopet til en individuell historie. Noen ganger kan det å dele opp en brukerhistorie i flere små bidra til å løse dette, mens andre ganger kan "rene tekniske historier" (technical-only) være mer passende. Disse rene tekniske historiene kan bli utfordret av interessentene på at de ikke leverer verdi som kan demonstreres for kunden eller interessentene.
Sammenligning med epos, temaer og initiativer I mange sammenhenger blir brukerhistorier både brukt og sortert i grupper av semantiske og organisatoriske årsaker. Bruken avhenger av ståsted, for eksempel om man ser fra et brukerperspektiv som produkteier i forhold til funksjoner, eller fra et bedriftsperspektiv med tanke på organisering av oppgaver. miniatyr|370x370pk|Eksempel på bruk av et historiekart, med epos på toppen for å strukturere historier. Mens noen foreslår å bruke "epos" og "temaer" som etiketter for enhver tenkelige form for gruppering av brukerhistorier, har begrepene en tendens til å bli brukt til sterk strukturering og estimering av arbeidsbelastninger. Eksempelvis har programvaren Jira en tilsynelatende hierarkisk organisert gjøreliste hvor det første nivået av gjøremål kalles "user-story", det andre nivået kalles "epics" (gruppering av brukerhistorier ), og det tredje nivået kalles "initiatives" (gruppering av epos). Initiativer er imidlertid ikke alltid til stede i produktutviklingsverktøy, og legger bare til et annet nivå av granularitet. I Jira eksisterer "temaer" (themes) for sporingsformål og gjør det mulig å kryssrelatere og gruppere elementer fra ulike deler av det faste hierarkiet.
Under denne bruken endrer Jira betydningen av temaer i et organisasjonsperspektiv (for eksempel hvor mye tid vi brukte på å utvikle temaet "xyz"). Dog er en annen definisjon på temaer at en gruppe med brukerhistorier, epos, funksjoner, osv. utgjør en felles semantisk enhet eller et mål. Det finnes sannsynligvis ikke en felles definisjon fordi ulike tilnærminger finnes for ulike metoder for produktdesign og -utvikling. I denne forstand foreslår noen også å ikke bruke noen form for harde grupper og hierarkier.
Epos Store brukerhistorier eller flere brukerhistorier som er nært beslektede kan summeres til et epos. En annen vanlig definisjon på et epos er en brukerhistorie som er for stor for en sprint.
Initiativ Flere epos eller brukerhistorier som er grupperte sammen hierarkisk. Mest kjent fra Jira.
Temaer Flere epos eller historier gruppert sammen etter et felles tema eller semantisk forhold.
Størrelse Vanlige tilnærminger til dimensjonering av brukerhistorier inkluderer:
Historiepoeng (story points): Brukerhistorier blir ofte gitt en "størrelse" basert på lagets oppfatning av hvor lang tid den kan ta å levere, og dette gjøres da da ofte ved å tildele et visst antall historiepoeng til historien. Et historiepoeng er en vilkårlig og inkonsekvent indikator på lagets oppfatning av størrelse på et tidspunkt. Poengfordelingen er vanligvis basert på en Fibonacciskala. T-skjortestørrelser: Denne metoden ligner historiepoeng ved at den er basert på lagets mening. Det er en mindre granulær indikator på arbeidets størrelse enn historiepoeng. COSMIC function points: Dette er en 2. generasjons ISO-standardisert funksjonell dimensjoneringmetodikk egnet for smidig programvareutvikling hvor ikke alle krav på forhånd er kjent. IFPUG function points: En 1. generasjons funksjonell dimensjoneringsmetodikk.
Kart over brukerhistorier miniatyr|518x518pk|Kart over brukerhistorier. En kart over brukerhistorier eller brukerhistorikart (story map) organiserer brukerhistorier i henhold til en fortellende flyt som presenterer det store bildet av produktet. Teknikken ble utviklet av Jeff Patton fra 2005 til 2014 for å minske risikoen for at prosjekter ble oversvømmet med svært detaljerte brukerhistorier som distraherte fra å realisere produktets hovedmål.
Under kartlegging av brukerhistorier har man gjerne arbeidsmøter (workshops) sammen med brukere for å identifisere de viktigste aktivitetene til virksomheten. Hver av disse aktivitetene kan involvere flere typer brukere eller "personas".
Linjen for det horisontale tverrgående narrativet trekkes deretter ved å identifisere hovedoppgavene til den enkelte brukeren som er involvert i disse forretningsaktivitetene. Denne horisontale linjen holdes gjennom hele prosjektet. Mer detaljerte brukerhistorier samles inn i tråd med vanlig praksis for brukerhistorier, men hver nye brukerhistorie blir enten satt inn i fortellingsflyten eller relatert vertikalt til en hovedoppgave.
Den horisontale aksen korresponderer med dekningen av produktmålene, og den vertikale aksen til behovene til de enkelte brukerne. På denne måten blir det mulig å beskrive selv store systemer uten å miste det store bildet.
Kart over brukerhistorier kan enkelt gi en todimensjonal grafisk visualisering av produktkøen. Øverst på kartet ser man overskriftene som historiene er grupperte under, vanligvis referert til som "epos" (store grovkornede brukerhistorier), "temaer" (samlinger av relaterte brukerhistorier) eller "aktiviteter". Disse identifiseres ved å orientere seg etter brukerens arbeidsflyt eller den rekkefølgen man ville forklart systemets oppførsel. Vertikalt (under eposene) blir de faktiske brukerhistoriene satt inn og ordnet etter prioritet. Den første horisontale raden er et "vandrende skjelett" (walking skeleton), og de under representerer økende raffinement.
Kart over brukerens reise Et brukerreisekart (user journey map) har til hensikt å vise det store bildet, men for en enkelt brukerkategori. Dens fortelling fokuserer på kronologi av faser og handlinger som en enkelt bruker må utføre for å oppnå sine mål.
Brukerreisekartet gjør det mulig å kartlegge brukeropplevelsen utover et sett med brukerhistorier. Basert på tilbakemeldinger fra brukerne kan de positive og negative følelsene gjennom hele brukerreisen identifiseres, og friksjonspunkter eller uoppfylte behov kan identifiseres på kartet. Denne teknikken brukes til å forbedre utformingen av et produkt, og gjør det mulig å engasjere brukere i en deltakende tilnærming.
Sammenligning med brukstilfeller Et brukstilfelle har blitt beskrevet som "en generalisert beskrivelse av et sett av interaksjoner mellom systemet og en eller flere aktører, hvor en aktør er enten en bruker eller et annet system". Mens brukstilfeller og brukerhistorier har noen likheter er det flere forskjeller mellom dem: