Har du noen gang sett på backloggen din og ønsket å slette alt og begynne på nytt? Vel, jeg har hatt den følelsen mer enn én gang, siden det ikke er enkelt å bygge og vedlikeholde produktbacklogger. Men for å vise deg hvordan du gjør backlogger på riktig måte og inspirere deg til å rydde opp i din egen, vil jeg dele fire eksepsjonelle eksempler på produktbacklogger med deg.
Hva handler produktbackloggen om i smidig utvikling og Scrum?
Produktbackloggen er et levende dokument som inneholder alle elementene som produktteamet, scrum masteren og utviklingsteamet planlegger å arbeide med for å bygge produktet sitt.
Den består av alt du trenger for å bygge og vedlikeholde produktet ditt, inkludert nye funksjoner, oppgaver knyttet til teknisk gjeld, forbedringer av tekniske prosesser fra din siste retrospektivøkt, oppgaver for automatisering av kvalitetssikring og mer.
Det viktigste kjennetegnet ved en produktbacklogg er at den er en prioritert liste, der elementene øverst har høyest prioritet, og teamet bør ta dem først når de planlegger sprintene sine (eller når de har ledig plass på kanban-tavlen).
Produktbacklogg vs. sprintbacklogg vs. produktveikart: Hva er forskjellen?
Innen smidig prosjektledelse, og særlig i Scrum-metodikken, er ikke en produktbacklogg den eneste listen over elementer som produkteieren oppretter for utviklingsteamet ditt. Det finnes også en sprintbacklogg og et produktveikart. Men hva er forskjellen mellom dem? La oss se nærmere på det.
Sprintbacklogg: Dette er et delsett av den større backloggen og inneholder bare elementene som scrumteamet har inkludert i den neste sprinten eller en annen type iterasjon, som et resultat av et sprintplanleggingsmøte. Elementene her er vanligvis godt bearbeidet og inneholder historiepoeng.
Produktveikart: Dette er et overordnet dokument som viser produktets viktigste funksjoner og milepæler. I motsetning til backloggen, som er mer taktisk av natur og inneholder beskrivelser av funksjoner, er produktveikartet strategisk og skal vise teammedlemmer og interessenter hvilken retning produktet beveger seg i, samt hvilke fokusområder som har høyest prioritet.
Nå som du og de viktigste begrepene er blitt ordentlig introdusert, går jeg rett over til å forklare hvordan du håndterer produktbackloggen din (og hvordan du, eh, ikke bør gjøre det).
Slik skal du ikke gjøre det: Her er et forferdelig eksempel på en produktbacklogg
Å forstå antimønstrene ved å opprette og håndtere produktbacklogger er sannsynligvis like viktig som å lære beste praksis. Grunnen er at hvis du ikke vet at noe er et antimønster, risikerer du å ha det i backloggen din og tro at det er noe normalt og vanlig.
For å se på noen av praksisene som kan redusere kvaliteten på backloggen din betydelig, kan vi se på eksempelet nedenfor.
Tilbake til eksempelet. Ta deg god tid til å undersøke det nøye.
Det ser forferdelig ut, gjør det ikke? Når vi ser på denne backloggen, vil de fleste av oss faktisk oppleve to følelser:
- Avsky over rotet blant elementene i denne backloggen.
- Skyldfølelse, fordi la oss innrømme det: Alle har hatt en backlogg som så slik ut (jeg også, selvfølgelig).
La oss nå bryte ned problemene vi finner i denne backloggen.
Have an account? Log In
Overflod av produktbackloggelementer
La du merke til at det var 665 saker i denne backloggen? Vel, den største backloggen jeg har hatt «gleden» av å håndtere, inneholdt over 2 500 elementer.
Problemet med en overfylt backlogg er at du nesten helt sikkert ikke vil klare å huske hva hvert element i den er, eller hvorfor du har plassert det på en bestemt plass eller med en bestemt prioritet i backloggen. Siden du ikke har noen anelse om hva disse oppgavene handler om, er det lite sannsynlig at du tar dem med til neste gjennomgang, diskuterer detaljene deres og inkluderer dem i den kommende sprinten.
Så ender du opp med et enormt, uhåndterlig rot som fortsetter å hope seg opp i det uendelige.
Feil prioritering av backlog
Et annet problem du kanskje har lagt merke til på denne backloglisten, er at det finnes arbeidsoppgaver med prioritet «Lavest» og «Lav» øverst – over oppgaver med prioriteten «Høyest».
Dette er et typisk eksempel på at backloggen din ikke er riktig prioritert. Det kan være mange grunner til dette, men den mest sannsynlige er at du har nedprioritert en oppgave med «Høy» prioritet ved å flytte den lenger ned i backloggen, men glemt å endre prioritetsfeltet.
Author's Tip
Uansett hvorfor du endte opp med rotete prioriteringer, er dette noe som kan skade produktet og teamet ditt. Ikke glem at backloggen din skal fungere som en «eneste sannhetskilde» for alle. Hvis det derfor finnes en oppgave med feil prioritet (for eksempel at den har fått høyere prioritet enn den burde ha), risikerer du at teamet ditt begynner å jobbe med den og ignorerer andre oppgaver som er viktigere.
Mangel på detaljer
La du merke til oppgaven som sier «Jeg ønsker sømløs integrasjon med alle sosiale medieplattformer»? LOL. Det er ikke engang en ordentlig brukerhistorie, med tanke på det enorme omfanget den sikter mot. Omfanget er så stort at du i praksis burde ha flere epos som dekker dette, der hvert epos inneholder historiene for én sosial medieplattform.
Bortsett fra det enorme omfanget er problemet med denne oppgaven (faktisk med alle oppgavene i denne backloggen) at den er vag. Brukerhistorier skal beskrive en spesifikk brukeropplevelse og handling.
Se for deg at du tar med denne historien til backloggforfiningsmøtet med Agile-teamet ditt. Du ville blitt møtt med en strøm av spørsmål om nesten alle aspekter ved historien.
«Hva mener du med sømløs?» «Hvordan ser integrasjonen ut?» «Hvilke sosiale medieplattformer skal vi integrere med?!»
«Jeg vil ha alt, og det nå»
Et annet faresignal du kanskje la merke til i backloggen, var at 70 % av oppgavene hadde prioriteten «Høyest». Dette er en annen typisk situasjon når du utelukkende baserer deg på interessentenes meninger når du fastsetter prioriteringer (og hver interessent anser sine oppgaver som viktige), uten å forsøke å vurdere dem objektivt og sammenligne viktigheten deres med andre oppgaver i listen.
Nå som vi har definert hvordan en dårlig backlog ser ut, skal vi fikse den og se på fire gode eksempler på backlogger ... slik at du kan gjøre backloggen din god igjen.
3 eksempler på backlogger gjort riktig
Før jeg viser deg disse eksemplene, vil jeg understreke at det ikke finnes én enkelt riktig måte å opprette en god backlog på. Hvordan backloggen din ser ut, vil avhenge av produktets art, modenheten, størrelsen på selskapet/teamet ditt osv.
I virkeligheten er en god backlog en backlog som skaper klarhet og samordning blant alle når det gjelder det nåværende og kommende omfanget av produktet ditt.
Det finnes imidlertid generelle måter å håndtere backloggen på som gjør den mer organisert og enklere å bruke for alle. Hvert av eksemplene nedenfor representerer en slik beste praksis.
Eksempel nr. 1: En backlog med seksjoner
Det er nesten aldri greit å ha en backlog med hundrevis eller tusenvis av oppgaver. Det er imidlertid vanlig og normalt å ha rundt 100 oppgaver. Men selv med hundre oppgaver i backloggen er det lett å glemme hva hver enkelt handler om, eller la dem ligge urørt lenge uten å legge dem til i de kommende sprintene.
For å gjøre backloggen mer organisert kan du vurdere å dele den opp i seksjoner.
Noen produktledere liker å bruke seksjoner til å gruppere oppgaver basert på fokusområder eller milepæler. Jeg foretrekker personlig å bruke etiketter for versjon, epos og komponenter på oppgavene til dette, og dele opp backloggen i seksjoner basert på omfanget av de kommende sprintene.
Dette er en god måte å tildele en sprint (eller i det minste en omtrentlig tidsplan for implementering) til de aller fleste oppgavene i backloggen på, og sørge for at ingen oppgaver blir forsømt.
En annen vanlig måte å administrere produktkøen med seksjoner på, er å gruppere elementer basert på statusen for detaljeringen/arbeidsflyten (dette er noe AI i produktkøadministrasjon kan hjelpe med). I dette tilfellet effektiviserer du prosessen med følgende seksjoner:
- Gjeldende sprint
- Klar for planlegging
- Klar for detaljering
- Produktkø
Det du gjør i dette tilfellet, er å legge til produktkrav og beskrivelser for elementene i produktkøen. Når kravene er klare, sender du dem til seksjonen «Klar for detaljering», som fungerer som omfanget for det neste detaljermøtet.
Etter at du har detaljert et element, flytter du det til seksjonen «Klar for planlegging», noe som indikerer at det er klart og at teamet kan inkludere det i den kommende sprinten.
Eksempel nr. 2: En produktkø med riktig plasserte komponenter, epos og versjoner
Segmentering av produktkøen vil helt sikkert gjøre den ryddigere og mer organisert. Begrensningen ved å kun bruke segmentering er imidlertid at du bare kan organisere produktkøen basert på ett kriterium (for eksempel sprintene, statusen for detaljeringen og så videre).
Heldigvis gir moderne verktøy for produktkøer deg et bredere utvalg av alternativer for å organisere gjøremålslisten for produktutviklingen basert på flere kriterier. Bare se på denne praktfulle produktkøen.
Ser den ikke velorganisert og behagelig ut for øyet? I dette spesifikke tilfellet har vi benyttet oss av følgende funksjoner for å gjøre produktkøen mer håndterlig:
Komponenter
Dette feltet/kjennetegnet beskriver tradisjonelt området av produktet der du vil legge til den aktuelle funksjonen. I eksempelet ovenfor er komponentene de separate produktene som utgjør Grammarly.
En annen vanlig måte å bruke komponenter på er å organisere historier/oppgaver basert på teknologien som kreves for å lage funksjonen. For nettapplikasjoner kan du for eksempel ha komponenter for frontend/backend som hjelper deg med å organisere arbeidet og avhengighetene mellom utviklere som spesialiserer seg på utvikling på henholdsvis klientsiden eller serversiden.
Versjoner/utgivelser
Med dette kjennetegnet dokumenterer du alle funksjonene og feilrettingene som Scrum-teamet ditt vil gi ut med en bestemt versjon av produktet. Versjonssporing i produktkøen har to svært verdifulle fordeler.
- Det hjelper deg med å planlegge sprintene og utgivelsene dine. Hvis du for eksempel planlegger en utgivelse om to uker, bør du under planleggingsmøtet sørge for å inkludere alle oppgavene som er ment for denne utgivelsesversjonen, i sprinten.
- Du kan dokumentere alt teamet ditt har lagt inn i en bestemt versjon og enkelt spore problemer tilbake når noe skjer i produksjon.
Se for deg for eksempel at folk begynner å få Captcha-feil i registreringsflyten på den nyeste versjonen, 1.3.2. Når du søker etter oppgaven som teamet brukte som grunnlag for å gjøre endringer i captcha-konfigurasjonene, ser du at den tilhører versjon 1.3.1. Det betyr at du enten må rulle tilbake til versjon 1.3.0 eller gjøre en hurtigreparasjon.
Epos
Jeg tror ikke jeg trenger å forklare hva et epos er, eller hva fordelene ved å bruke det er. Men hvis du vil gå i dybden på beste praksis og de minste detaljene ved epos, kan du ta en titt på vår guide til epos (ordspill tilsiktet).
More Articles
Eksempel nr. 3: En produktkø med riktig mengde detaljer for hver seksjon
Dette er en beste praksis du kanskje har støtt på i mange bøker og teoretiske tekster om smidig produktledelse. Selv om vi har en tendens til å bli litt mer skeptiske til teoretiske konsepter jo mer erfaring vi får, er dette faktisk nyttig i praksis.
Ideen er altså at elementene øverst bør ha mange detaljer, og ideelt sett bør du ha ført dem gjennom en detaljering av produktkøen minst én gang. Elementene nederst i produktkøen bør derimot ha få detaljer, ettersom det er stor sannsynlighet for at du lærer noe nytt om produktet og sluttbrukerne dine, og at dette elementet blir utdatert.
Det betyr at hvis elementet øverst i produktkøen ser slik ut (eller er enda mer detaljert enn dette):
Brukerhistoriene nederst i arbeidskøen bør ha langt færre detaljer og se slik ut:
Og alle brukerhistoriene og initiativene du har midt i arbeidskøen, vil ha et middels detaljnivå.
Eksempel nr. 4: Jeg vet at det er åpenbart, men … en ryddig arbeidskø
Jeg vet at det ikke er enkelt å holde arbeidskøen ryddig. Jeg har vært der mange ganger, og jeg vet at det kan føles som et ork. Men å ikke gjennomgå alt i arbeidskøen og huske å fjerne utdaterte elementer er viktige faktorer som avgjør kvaliteten på arbeidskøen.
Det er ikke alltid enkelt å slette ting fra arbeidskøen. Det finnes virkelig mange fine funksjoner der ute som du håper å kunne utvikle en dag (hovedsakelig funksjoner som er «kjekt å ha»), og noen ganger vil du egentlig ikke kvitte deg med dem. Men på et visst tidspunkt må du innse at du aldri kommer til å implementere dem. Og selv om du skulle gjøre det, ville det bety at du ikke har flere funksjoner med høy prioritet igjen, noe som generelt ikke er et godt tegn.
Noen ganger er det interessentene dine som har opprettet disse utdaterte elementene i arbeidskøen. Før du fjerner dem, prøver du å spørre om forespørselen deres fortsatt er aktuell, og svaret er nesten alltid ja. Vel, hvis forespørselen er mer enn 6 måneder gammel og de allerede hadde glemt den, kan du bare overbevise dem om at det ikke er noe som haster (hvis det hadde gjort det, ville de ha fulgt den opp flere ganger) og slette den.
En god arbeidskø er den som fungerer best for deg
Hvis du tok hensyn til alle anbefalingene her, ville du da hatt en god arbeidskø? Vel, de vil hjelpe, men de garanterer ikke at den blir utmerket.
Ikke glem at formålet med arbeidskøen er å være en enkeltstående sannhetskilde for alle. Så i tillegg til disse anbefalingene må du ta hensyn til behovene og arbeidsstilen til teamet og interessentene dine, og bygge arbeidskøen på en måte som hjelper dem med å holde seg på samme side.
Denne veiledningen om gode arbeidskøer er en del av en større serie om alt innen Agile. Abonner på nyhetsbrevet vårt for å få flere veiledninger og innsikter som denne levert til innboksen din annenhver uke!
