Lær deg å elske din backlog <3 2

Backlog har en skikkelig kjip klang. Det høres ut som om man henger etter. Men backlogen er et fantastisk redskap for alle som har en hektisk hverdag med mange baller i lufta.

Det er mange som elsker å skrive lister over ting i hverdagen. Jeg er en av dem. Lister gjør at jeg får ro i sjela. Lista er min venn. Backlogen er min bestevenn. Jeg føler ikke alle har blitt ordentlig introdusert med backlogen, siden det virker som om mange ikke liker den. Jeg håper du vil knytte et tettere bånd med den etter dette.

Hva er en backlog

Ordet ble orginalt brukt om den store vedkubben som ligger innerst i ovnen eller bålet. Kubben som bidrar til at bålet brenner lenge og holder en jevnt temperatur.

En backlog er en liste over ønsket funksjonalitet og behov. Den kan lages enkelt i Excel eller Google Docs Spreadsheets. Eller for litt viderekommende i programmer som Symphonical, Trello, Basecamp eller andre prosjektverktøyer (det finnes en million forskjellige av disse og de fleste prosjektledere har sine hjertebarn). Det er ikke viktig hvor backlogen befinner seg, sålenge alle som trenger det har tilgang og forstår den.

Hva er poenget med en backlog

Hensikten er å skape enighet og oversikt over hva man jobber med til en hver tid. Backlogen er altså en arbeidsliste, og alle bestillinger (altså igangsetting av de ulike oppgavene) kan gjøres via denne. Hvis det er stor entusiasme internt i din bedrift for hva som trengs på nettstedet deres, og du sitter som mottaker av disse ønskene, er backlogen riktig sted for å få kontroll.

Backlogen er også et verdifullt verktøy for å sikre at konseptet, basert på de underliggende funnene av brukerbehov fra analysefasen, blir godt ivaretatt når man går over i utviklingsfasen.

Hvem eier backlogen

Backlogen bør eies av prosjekteier hos kunden mens prosjektet pågår. Erfaringsvis er den aller beste eieren bestilleren av prosjektet, altså samme person som mottar fakturaen på arbeidet som foregår. I oppstarten av et prosjekt er det viktig å avklare hvem som skal eie backlogen, og i hvilken form den skal eksistere, når prosjektet går over i en oppfølgingsfase (hvis du ikke henger med nå, anbefaler jeg å lese «Når er man egentlig ferdig»). For det vil alltid være en backlog. Det er det som er så fint!

Hva er genialt med backlogen

Idesamleren
«I natt drømte jeg om noe kjempelurt vi burde gjøre!». Man kan legge inn ideer som dukker opp underveis i prosjektet slik at man husker dem senere. Dette motiverer og gjør at folk føler seg hørt. Et prosjekt bør alltid ha en «Yes, and …»-holdning, dette motiverer alle deltakerne til å være kreative -selv om forslagene nødvendigvis ikke hører inn under gjeldende prosjekt. Man fanger opp alle gode ideer samtidig som man holder fokuset på de viktigste tingene og målene for prosjektet.

Oversikt
«Hva jobber de med nå mon tro?» Alle vet hva alle holder på med til en hver tid. Hvis man glemmer hva man ble enige om at skulle gjøres til neste møte, kan man gå inn og se i backlogen.

Viderekommunisering internt
«Hvordan ligger de an med den greia jeg bestilte?» Hvis prosjekteier trenger å rapportere status på en oppgave videre internt kan han/hun enkelt hente det ut fra backlogen. Hun kan vise sine kollegaer at hun har stålkontroll til en hver tid.

Gjennomsiktighet
«Har de fått med alt? Husker de det jeg sa i forrige møte?» Ingen elefanter. Alt er ute i det åpne.

Estimater
«Hvor store budsjetter er det smart å sette av til oppfølging og videreutvikling?» Man kan utifra størrelsen på backlogen og de grove estimatene få en god pekepinn på hvordan budsjettene bør se ut fremover.

Testskjema til akseptansetest
«Hva bør jeg teste før lansering?» Backlogen kan med noen enkle grep gjøres om til et skjema for akseptansetest (altså testen prosjekteier bør gjøre før nettsiden lanseres). Legg inn hvilke nettlesere det skal testes i, på hvilke dingser (nettbrett, mobiltyper, mac, pc etc) du ønsker at det skal testes på, så har du det viktigste. I løpet av prosjektet vet man mye om brukerne sine, og det er som regel enkelt å velge disse.

backlog_eksempel2

Hvordan lage en ryddig backlog

Det er ulike måter å strukturere en backlog på. Jeg synes dette er de mest nødvendige punktene:

ID-nummer
Siden man flytter opp og ned på oppgavene i backlogen etter prioritet er det lurt å ha et ID-nummer på oppgaven. Dette gjør det også lettere å snakke sammen om oppgavene. Prosjektstyringsprogrammene fikser dette automagisk for deg, men om du har en enkel backlog i listeformat er det smart å legge til dette manuelt. Jeg pleier å ha en to bokstavsforkortelse + årstall + løpenr, eks “NR 14-01″.

.

Behovet
Det bør finnes en god og kortfattet beskrivelse av behovet som skal dekkes i oppgaven. Det kan for eksempel gjøres i form av en userstory (se forklaring under).

Funksjonalitet
Det bør også finnes en beskrivelse av funksjonen som skal dekke behovet. Denne ruten vil sannsynligvis (og bør!) stå tom en god stund inn i prosjektet. Her er det nemlig viktig å gi utøverne som sitter på kjernekunnskapen (designerne og utviklerne) rom til å være kreative. Hvilke funksjoner som skal dekke de ulike behovene defineres etter at analysen er gjennomført, og konsept for nettstedet er valgt.

Det finnes ikke noe fasitsvar på nøyaktig når backlogen bør detaljeres og utdypes, men retningen og de overordnede designprinsippene bør være valgt. På den måten sikrer man at helheten ivaretas og at man har en rød tråd gjennom hele prosjektet. I prosessen med å velge funksjonalitet som skal løse behovet bør utvikler også være en del av det tverrfaglige prosjektteamet. Utvikler sitter på kjernekompetansen på dette området og kan foreslå de beste alternativene for å støtte opp rundt designet.

Status på oppgavene
Man kan gjøre denne statusen så detaljert som det er behov for. Jeg liker å holde meg litt overordnet og bruker som regel statuser som: ikke påbegynt, påbegynt, trenger avklaring, til godkjenning, godkjent osv. Når backlogen opprettes bør det også avklares hvilke statuser som skal brukes, hva de betyr og hvem som endrer fra en status til en annen.

Prioritet
Denne settes av kunden og oppdateres til en hver tid i felles planleggingsmøter. Når man prioriterer oppgavene må man hele tiden ha målene for nettstedet friskt i minnet. Kjappeste veien til en god nettside er en streng prioritering mellom hva man kan, bør og må ha.

Estimat
Man bør sette inn estimat på de ulike oppgavene så godt det lar seg gjøre. Det er naturlig at disse er veldig grove til å begynne med, og blir mer realistiske etterhvert som detaljeringen faller på plass. En ide på grovestimering er å bruke S, M, L, XL . Poenget med å estimere før man har snøring på tidsomfanget er at prosjekteier skal kunne prioritere oppgaver i forhold til hverandre, og også vite når et ønske krever større budsjetter.

Kommentarer
Ofte har man behov for å legge til ytterligere info eller utdyping av oppgaven. For eksempel hvis man har gjort en avklaring som spisser oppgaven ytterligere. Dette kan man gjøre i et kommentarfelt.

Man kan også ha med ønsket leveringsdato, hvem som la inn ønsket, hvilken fase ønsket mest sannsynlig hører inn under osv.. hvis man vil. Men jeg tenker «jo enklere, jo bedre»! Jo mer man legger til, desto vanskeligere blir det for alle å henge med. På samme måte som en uprioritert nettside gjør det vanskelig å få oversikt og finne fram til det du leter etter.

Tips:
Sorter backlogen etter prioritet! Da ligger det viktigste på toppen og det er enkelt å se hva som skal gjøres til enhver tid.

Userstory

Userstory er et ord man ofte møter på hvis man leser om metodikken Scrum. Dette er én måte å vinkle behovet fra en brukers ståsted, og kan gjøres slik: «Som bruker ønsker jeg å donere penger.» Funksjonaliteten som støtter oppunder dette kan da f.eks være et betalingsskjema. Men det er mange måter å løse denne userstoryen på, så hvis man former krav på denne måten vil de kreative utøverne i prosjektet få godt spillerom til å gjøre det de synes er gøy- løse problemer.

Man kan også ha userstories som dekker redaktørens behov. De kan f.eks beskrives slik «Som administrator ønsker jeg at jeg kan legge til flere kategorier med tilhørende priser under abonnementsproduktene».

Det er lurt å avklare hvilke roller userstoriene skal inneholde når man oppretter backlogen. På denne måten unngår man å bruke ulike begreper på samme rollen: eks Redaktør, Administrator, Kundenavn eller Bruker, Kunde, Sluttbruker.

Obs!
Det er viktig å gjøre en grundig analyse på hva brukerne faktisk ønsker før man fastsetter userstories. Hvis ikke ender man fort opp med for simple userstories som ikke gjenspeiler helheten eller støtter godt nok opp rundt målene for nettstedet. Man kan godt sette opp hypoteser, men vær forberedt på å justere disse etter analysen og kanskje til og med på nytt etter en brukertest.

Når prosjektperioden er over

Etter endt prosjektperiode når man går over i en oppfølging- og vedlikeholdsfase synes mange det er praktisk å legge backlogen over i et supportverktøy som Jira, Fogbugz eller lignende . På denne måten kan man sammen planlegge f.eks kvartalsvise produksjonsettinger av ny funksjonalitet. Nå blir det viktig å røkte backlogen godt. På samme måte som du ønsker å holde nettsiden relevant og oppdatert, bør du også passe på at backlogen ikke gror ut av fasong. Slett det du vet at aldri vil bli gjort, og fortsett med en streng og god prioritering.

Tips:
Legg alle oppgaver som er ferdigstilte i et arkiv. Ikke slett dem! På denne måten kan du gå inn og glede deg over alt som er gjort. Det er lett å fokusere på alt man ikke har fått gjort ennå, og glemme alt man faktisk har fått til. Det er jo dette brukerne dine ser. Alt det fine som ligger live! Så ikke tenk på backlogen som “det du aldri fikk gjort” eller “det vi ikke rakk innenfor budsjettrammene”. Tenk på den som fremtiden!

Tenk på den store kubben innerst i peisen, den som holder bålet i gang. Det er jo helt fantastisk at man har så mye gøy å glede seg til. Og at du har stålkontroll på bedriftens vegne.

Lenge leve backlogen! <3

Er backlogen din bestevenn? Bor du tilfeldigvis i Bergen? Vi er på jakt etter en god prosjektleder til vårt nye team i Bergen. Les litt om hvordan vi jobber i Netlife Research her!

Randi BB Govertsen

Randi er prosjektleder med et bankende hjerte for begeistringsledelse.

Flere artikler av Randi CV

2 kommentarer

  1. Enig, Randi – en backlog er gull og må stelles godt med.

    Det fine med arkivet over ferdigstilte aktiviteter som du snakker om, er at det blir til prosjektets back catalogue. Altså en komplett oversikt over alle ønsker og ideer som et prosjekt har gitt ut. Derfra kan du velge de som ble mest populære, og sette sammen prosjektets greatest hits.

    De kan du stable ved siden av greatest hits fra de andre prosjektene dine. Ta med de urealiserte ideene du mener har størst hitpotensial også, du vil trenge dem til bonusspor. Snart har du en imponerende samling å plukke godbiter fra når du skal komponere backlogen for ditt neste prosjekt.

    Og husk: Alle user stories i backlogen som ikke kan bevise at de er til nytte for brukerne, havner i black lodge. Der må de vandre hvileløst rundt til evig tid sammen med en liten mann i rød dress som danser rart og snakker baklengs. Dritskummelt.

  2. Greatest hits, det var jo et supert innspill! Det har jeg ikke brukt før. Takk for tipset!

    Og ja, Black Lodge er et fint sted for alle de unyttige oppgavene. Vanskelig å finne dem fram på nytt da. ;-)

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>