Produktkø kontra sprintkø: Viktige forskjeller

Backlogger er ryggraden i smidige arbeidsflyter og leder team fra idé til gjennomføring. En vanlig fallgruve er imidlertid å skille mellom produktbacklogger og sprintbacklogger – en feil som kan føre til feiljusterte prioriteringer, ineffektive sprinter og frustrerte team.

Selv om mange av oss har erfaring med å arbeide med programvare for håndtering av backlogger, kan feil bruk av disse to forskjellige verktøyene skape mer forstyrrelse enn klarhet.

Så hvordan sikrer vi at backloggene våre fungerer for oss og ikke mot oss? Å forstå deres unike roller handler ikke bare om definisjoner – det handler om å løse vanlige problemer i arbeidsflyten og optimalisere teamsamarbeidet. La oss bryte ned forskjellene og se på hvordan de kan brukes effektivt.

Hva er en produktbacklogg?

En kort og forenklet forklaring på hva en produktbacklogg er – den inneholder alle funksjonene og aktivitetene du og utviklingsteamet ditt planlegger å arbeide med.

For en mer strukturert definisjon kan vi se på Atlassian.

Du har kanskje lagt merke til at folkene hos Atlassian fremhevet to viktige konsepter da de definerte backloggen.

1. Den er prioritert.

En enkel liste over ting som skal bygges, vil enten føre til et stort rot eller et produkt som ikke er i stand til å løse brukernes problemer på en god måte. En liste over funksjoner er derfor egentlig ikke en produktbacklogg med mindre du prioriterer den.

2. Den er avledet fra veikartet.

Jeg har sett så mange backlogger som ganske enkelt var resultatet av at alle delte funksjonsidéene sine og la dem til i backloggen. Dette fører til et rot og et produkt som ser ut som Frankensteins monster. Hvis du vil at backloggelementene dine skal bidra til å nå et bestemt produkt- eller forretningsmål, må du bygge backloggen basert på veikartet og produktvisjonen din.

Hovedformålet med å ha en backlog i utgangspunktet er å skape én felles kilde til sannhet for alle i virksomheten. Det bør alltid finnes én backlog, og alle bør bruke den som referanse når de bestemmer hva de skal gjøre videre.

I tillegg er produktbackloggen et godt verktøy for å legge til rette for prioritering for deg og interessentene dine, siden du har alt du trenger å gjøre, samlet i én liste.

Hva bør en backlog inneholde?

Forutsatt at du bruker et av de smidige rammeverkene, vil produktbackloggen din bestå av følgende elementer:

• Epics: Store funksjoner som hjelper deg med å nå bestemte produktmål, for eksempel å øke konverteringen, løse et spesifikt brukerproblem eller forbedre brukerens reise gjennom produktet. Kommentarfunk­sjonen i Google Dokumenter er et eksempel på dette. Epics består vanligvis av mindre «underfunksjoner» kalt brukerhistorier.
• Brukerhistorier: Små funksjoner eller deler av en funksjon som kundene dine kan bruke. I Google Dokumenter-funksjonen ovenfor vil «å nevne noen i en kommentar» eller «å løse en kommentar» være typiske eksempler på historier under denne epicken.
• Tekniske oppgaver: Arbeidsoppgaver utviklingsteamet ditt må utføre, men som ikke er knyttet til funksjonene i backloggen. Eksempler på slike oppgaver er å sette opp en sikkerhetskopidatabase, refaktorere en mikrotjeneste eller optimalisere spørringshastigheter.
• Feil: Det er ikke en ekte backlogg hvis den ikke inneholder noen feil. Uansett hvor godt du utvikler og tester funksjonene dine, vil disse små parasittene alltid dukke opp. Derfor må du oppbevare, følge opp og håndtere dem et sted. Beste praksis er å lagre dem i backloggen og prioritere dem på samme måte som alle andre backloggelementer.

Slik vil en typisk produktbacklogg se ut:

P.S. Les artikkelen vår om 3 eksempler på produktbacklogger som er laget på riktig måte hvis du ønsker mer veiledning.

La oss nå forstå produktlederens rolle når det gjelder arbeid med backloggen.

Hvem har ansvaret for å håndtere backloggen?

Kort sagt – produktansvarlig er kongen over produktkøen. Vedkommende har nøklene til hva som bygges, i hvilken rekkefølge og hvorfor. Produktkøen er deres domene, og de har det overordnede ansvaret for å sikre at den forblir i tråd med produktvisjonen, brukernes behov og virksomhetens mål.

Det betyr ikke at produktansvarlig er den eneste som arbeider med produktkøen. Utviklere, designere og andre teammedlemmer kan foreslå eller til og med legge til elementer, men alle endringer bør gjøres under oppsyn av produktansvarlig. Tross alt fører en kaotisk produktkø til et kaotisk produkt.

Produktansvarliges viktigste ansvarsområder for produktkøen omfatter:

• Prioritere produktkøen – Sikre at det mest verdifulle og virkningsfulle arbeidet tas først.
• Forbedre den sammen med teamet – Regelmessig gjennomgå, oppdatere og bryte ned elementer for å holde arbeidet tydelig og gjennomførbart.
• Kommunisere prioriteringer og endringer i produktkøen – Holde interessenter informert slik at det ikke oppstår overraskelser.

Ettersom produktkøen er et levende dokument, utvikler den seg hele tiden. Nye ideer oppstår, prioriteringer endres, og enkelte funksjoner blir fjernet helt. Denne fleksibiliteten er et grunnleggende prinsipp i Agile – produktkøen bør gjenspeile de nyeste realitetene, ikke en rigid og utdatert plan.

En godt håndtert produktkø er ikke bare en oppgaveliste; den er et strategisk verktøy som hjelper team med å bygge riktig produkt til riktig tid. Og i sentrum for det hele? Produktansvarlig, som holder nøklene.

Opprette og håndtere en produktkø – en grunnleggende innføring

Du begynner å bygge den første versjonen av produktkøen så snart produktplanen er ferdig. Vanligvis tar du alle de viktigste funksjonene og arbeidsdelene fra produktplanen og gjør dem om til epos i produktkøen.

Deretter begynner du å utarbeide produktkravdokumentene for hvert av dem og oppretter epos basert på oppdelingen av funksjonaliteten i PRD-en din.

Men som en naturlig konsekvens av produktutvikling vil du ende opp med å stadig endre disse eposene, legge til frittstående brukerhistorier og feil for å få en produktkø som ligner på den de fleste av oss arbeider med. Jeg mener, en rotete en.

Men det er ganske enkelt å vedlikeholde produktkøen hvis du:

• Gjennomfører regelmessige økter for forbedring av produktkøen.
• Setter av tid i neste sprint til å gjennomføre omfattende feilrettinger og rydde dem bort fra produktkøen.
• Ikke lar alle legge ideene sine til i produktkøen uten å rådføre seg med deg først.
• Prioriterer produktkøen kontinuerlig.
• Bruker kartlegging av brukerhistorier for å få en tydelig oversikt over hva som må gjøres.

Når det gjelder det siste punktet, finnes det to hovedteknikker for prioritering som jeg vil anbefale at du bruker, basert på min omfattende erfaring med å prøve ut et dusin av dem.

MoSCoW

Dette er en ganske enkel teknikk som grupperer elementene i produktkøen i disse fire kategoriene:

• Må ha: Når funksjonen inngår i en sentral brukerreise, og du ikke kan løse brukernes problemer uten den. Spotify-spillelister er for eksempel noe man må ha.
• Bør ha: En betydelig forbedring av brukerreisen. For Spotify ville det vært muligheten til å søke etter ferdiglagde spillelister for humøret eller aktiviteten din.
• Kan ha: Noe som gleder brukeren, men der fraværet ikke er avgjørende. Spotify kunne brukt bevegelser til å endre sangen i stedet for knapper.
• Skal ikke ha: Funksjoner eller initiativer som du, interessentene dine eller teamet ditt vurderte som unyttige under møter for forbedring eller prioritering.

Som du ser, er MoSCoW en ganske enkel teknikk. Og det er én av grunnene til at jeg liker å bruke den, fordi den er svært enkel å forklare for alle i rommet og få dem til å bruke den også når de velger oppgaver med lav eller høy prioritet fra listen over elementer dere arbeider med.

Kano

En annen enkel teknikk som lar deg se på de aktuelle funksjonene fra brukernes behovsperspektiv. Her grupperer du funksjonene dine i disse kategoriene:

• Grunnleggende behov: Fraværet av dette er en avtalebryter for brukeren. På et hotellrom ville det vært at sengen har rene laken.
• Ytelsesbehov: Funksjoner hvis mengde eller tilstedeværelse direkte øker brukertilfredsheten. Det kan være interiørdesignet på hotellrommet eller tilgjengeligheten av klesvask- eller frokosttjenester.
• Begeistringsbehov: Fraværet av disse vil ikke redusere tilfredsheten. Men tilstedeværelsen av dem vil absolutt øke den. Det kan være en søt håndklesvane i origami på sengen på hotellrommet.

Her er en oversikt som illustrerer forholdet mellom disse typene funksjoner og brukertilfredshet i Kano-modellen.

For å oppsummere er produktkøen teamets gjøremålsliste, som produkteieren (eller produktteamet) oppretter og vedlikeholder ved hjelp av et bredt utvalg av verktøy og teknikker for håndtering av produktkøer.

Hva er en sprintkø?

Nå som selve produktkøens natur er tydelig for oss, skal vi forstå hva sprintkøen handler om (tips: den innebærer ikke trening.)

Scrum.org definerer sprintkøen som den delen av produktkøen som Scrum-teamet har valgt å fullføre i løpet av den kommende sprinten. I Scrum-rammeverket er den ett av de sentrale Scrum-artefaktene som hele teamet arbeider med.

Som definisjonen antyder, er hovedformålet med sprintkøen å tydelig definere arbeidsomfanget teamet må konsentrere seg om under sprinten.

Prosessen med å bygge sprintkøen finner vanligvis sted under planleggingsmøtet for sprinten. Her vil du vanligvis se følgende aktiviteter:

1. Produktlederen definerer målet for sprinten.
2. Teamet begynner å velge en gjennomførbar liste over leveranser som kan hjelpe dem med å nå dette målet.
3. Teamet bryter historiene ned i tekniske oppgaver og estimerer dem.
4. De ser på kapasiteten og hastigheten fra tidligere sprinter for å bekrefte at sprintkøen er gjennomførbar.

I motsetning til produktkøen, der produktlederen er den eneste eieren, ligger ansvaret for å opprette og vedlikeholde sprintkøen hos Scrum-teamet. Siden de er personene som utfører oppgavene som kreves for å bygge funksjonene, er de best egnet til å avgjøre størrelsen og omfanget av sprintkøen.

I motsetning til mange andre Scrum-artefakter, som noen team kan velge å ignorere (det er helt greit – du tilpasser Scrum til teamet ditt, ikke omvendt), ser sprintkøen ut til å være den som nesten alle bruker. Det finnes gode grunner til det. Sprintkøen gir deg spesielt:

• Tydelig arbeidsomfang: Teamet har en god forståelse av arbeidet de forventes å utføre i neste iterasjon.
• Bedre fokus: Med et tydelig arbeidsomfang og en Scrum-master som kjemper mot alles forsøk på å legge til nye oppgaver i sprinten, trenger teamet ikke å konsentrere seg om annet enn elementene i sprintkøen.
• Bedre fremdriftssporing: Siden ingen elementer kommer inn i eller forlater sprintkøen, er det relativt enkelt å se hvor godt teamet ligger an med å nå sprintmålet.

Når det gjelder det tredje punktet, har de fleste smidige verktøy innebygde rapporteringsverktøy for sprinter som automatisk sporer teamets fremdrift for deg. En av de mest populære rapportene for dette er et nedbrenningsdiagram.

Dette diagrammet består av to linjer som går nedover. Den grå linjen viser teamets hypotetiske ideelle fremdrift. Den røde linjen viser derimot den faktiske fremdriften. Jira (verktøyet som vises i skjermbildet) måler disse linjene basert på det totale antallet historiepoeng teamet har igjen å fullføre. Når noen lukker en oppgave, synker derfor den røde linjen med et antall som tilsvarer de estimerte historiepoengene for oppgaven.

Opprette og administrere en sprintkø

Prosessen med å opprette en sprintetterslep begynner med et produktetterslep som ennå ikke er bearbeidet. Produkteiere gjennomfører regelmessige møter for bearbeiding av etterslepet (også kalt foredling), der teamet:

• Stiller PM-en spørsmål om designet og kravene for å få en klar forståelse av hva produktteamet forventer at de skal bygge.
• Utfordrer noen av punktene i kravene hvis de er tidkrevende å lage eller vil føre til tekniske vanskeligheter.
• Fordeler ansvaret for hvert element i etterslepet til den lagkameraten de mener passer best til den aktuelle oppgaven.
• Estimerer størrelsen på oppgaven eller brukerhistorien ved hjelp av en av de populære teknikkene, for eksempel Fibonacci-tall kombinert med planleggingspoker.

Forutsatt at teamet har bearbeidet nok oppgaver til neste iterasjon, gjennomfører teamet et sprintplanleggingsmøte der de forplikter seg til en viss mengde oppgaver fra produktetterslepet. I det øyeblikket teamet forplikter seg til dette og starter sprinten, blir denne gruppen av oppgaver til sprintetterslepet.

For å håndtere sprintetterslepet gir smidigmetodikken oss flere verktøy, blant annet:

• Daglige statusmøter der hvert teammedlem viser fremdriften sin til teamet og rapporterer om eventuelle hindringer som bremser dem.
• Burndown- og burnup-diagrammer som visualiserer teamets samlede fremdrift.
• Demonstrasjonsmøter på slutten av sprinten, der teamet viser frem resultatene av arbeidet sitt til produktteamet og får konkrete tilbakemeldinger på designet og funksjonaliteten i funksjonene de har bygget.

Til slutt har vi retrospektive møter. De hjelper deg ikke direkte med å håndtere sprintetterslepet, men du får diskutert prosessene som vil forbedre kvaliteten og effektiviteten i håndteringen av det.

Viktige forskjeller mellom produktetterslep og sprintetterslep

For å forstå forskjellene mellom disse tilsynelatende like konseptene bedre, vil jeg først gi deg en oversikt side ved side over hvordan de skiller seg fra hverandre, og deretter forklare hvert element mer detaljert.

Selv om oversikten i seg selv enkelt kan forklare hvordan de er forskjellige, har du kanskje fortsatt spørsmål om bestemte aspekter. La meg derfor gå gjennom dem én etter én.

Tidsramme: Produktetterslep representerer planen din på mellomlang til lang sikt, ettersom de gjenspeiler produktets veikart og visjon. Planleggingshorisonten kan derfor variere fra flere sprinter til et par år.

Sprintetterslep har derimot en svært kort tidsramme, ettersom de representerer elementene teamet planlegger å levere i neste sprint (som vanligvis varer i 1–4 uker).

Ansvar: Som vi allerede har nevnt, er den endelig ansvarlige for produktetterslepet noen fra produktteamet (vanligvis produkteieren som er tilknyttet teamet). Scrum-teamet kan bidra til etterslepet, men de kan bare gjøre det gjennom PM-en.

Situasjonen er annerledes med sprintetterslepet. Den eneste måten en PM kan påvirke det på, er ved å fastsette sprintmålet. Utover det er det Scrum-teamet som har myndighet til å opprette og administrere det.

Detaljnivå: Ettersom elementene i et produktetterslep kan representere arbeid over flere kvartaler eller til og med år, er det ikke realistisk at PM-en har alle elementene beskrevet i detalj. Jeg fraråder faktisk dette på det sterkeste, siden det alltid er en mulighet for at du ender opp med å slette mange funksjoner fra det, og det ville være bortkastet tid å beskrive dem grundig.

Vanligvis vil elementene med høyest prioritet ha et høyt detaljnivå, mens alt annet har en grov beskrivelse.

For at brukerhistoriene skal kunne tas inn i sprintetterslepet, må de imidlertid inneholde alle tilgjengelige detaljer. Ellers vil Scrum-teamet nekte å implementere brukerhistoriene hvis de ikke har en klar forståelse av hva som forventes av dem.

Formål: Produktetterslepet er «mellomleddet» mellom svært vage strategiske planer og svært spesifikke tekniske implementeringsdetaljer. Det fungerer som verktøyet ditt for å uttrykke de strategiske planene dine i form av en oppgaveliste.

Sprintetterslep er derimot svært taktiske av natur og har som mål å gi teamet en klar, kortsiktig handlingsplan og et tydelig omfang.

Fleksibilitet: Produktetterslep er levende dokumenter som endres hele tiden. På grunn av den langsiktige karakteren har de ikke noe annet valg enn å endres basert på nye prioriteringer, tilbakemeldinger fra brukerne og markedsforhold, slik at produktet ditt forblir levedyktig.

Sprintetterslep er det stikk motsatte. Selv om jeg på det sterkeste oppfordrer deg til å videreutvikle produktetterslepet kontinuerlig, er det helt uaktuelt å endre elementene i et sprintetterslep, siden du da ender opp med å bryte alle teamets forpliktelser og planer.

Slik fungerer produktetterslepet og sprintetterslepet sammen

Som nevnt er sprintbackloggen det mer presise og avklarte delsettet av produktbackloggen. Du regner den fortsatt som en del av backloggen frem til det nåværende sprintet er over. Deretter forlater de fullførte historiene backloggen, mens de ufullstendige historiene føres inn igjen øverst på prioritetslisten.

Når det gjelder flyten av funksjoner mellom disse to backloggene, kan du ikke bare fylle sprintbackloggen med elementer fra produktbackloggen, men også gjøre det motsatte.

Uansett hvilken vei historiene går, er det avgjørende å sikre en smidig overlevering. Her er det jeg foreslår at du legger merke til:

• Alt som kommer inn i sprintbackloggen, bør inneholde åpne spørsmål til scrumteamet. Ellers blir du en blokkering for sprintens fremdrift. Den beste måten å håndtere dette på er å lage en liste over Definisjon av klar (DoR) sammen med teamet og følge den.
• Alt som kommer inn i sprintbackloggen, bør ha estimater. Ellers blir teamets forpliktelser og planer feil. Det blir også vanskelig å bruke burndown-diagrammer til å overvåke fremdriften.
• Når du bygger sprintbackloggen, bør du alltid spørre teamet tydelig om de er komfortable med arbeidsmengden. Folk har en tendens til å overbelaste seg selv og ender opp med sprinter som bare er halvferdige.
• Når du tar ufullstendige elementer ut av sprinten ved slutten av den, bør du alltid følge opp dette i retrospektivmøtet. På denne måten kan du finne ineffektivitet i prosessen og eliminere den.

Overordnet sett ser hele prosessen slik ut.

I tillegg til tips om hvordan du kobler disse to sammen, vil jeg hjelpe deg med å håndtere begge på riktig måte ved hjelp av noen gode fremgangsmåter fra min erfaring.

Beste fremgangsmåter for håndtering av produktbackloggen

Det kan enten være givende eller forferdelig å eie en produktbacklogg, avhengig av hvor godt du håndterer den. Dette er hva jeg gjør basert på mange års erfaring:

• Regelmessig opprydding: Finn motet til å fjerne elementer fra backloggen som det er svært usannsynlig at kommer i utvikling.
• Kommunikasjon med interessenter: Ha regelmessige prioriteringsmøter på overordnet nivå med interessentene dine. På denne måten samsvarer planen de har i tankene, med det du har i backloggen.
• Egen liste for elementer med usikker fremtid: Noen ganger kommer du eller en interessent med ideer som kanskje skal bygges, og kanskje ikke. For å unngå å fylle backloggen med dem bør du oppbevare dem i en separat liste et sted. Legg dem først til i backloggen når du vet at dere kommer til å bygge dem.

Til slutt foreslår jeg at du benytter deg av de mange verktøyene og malene som finnes for produktbacklogger, for å fremskynde opprettelsesprosessen. Her er en samling fra ClickUp som du kan bruke.

Hvis du vil lese om flere gode fremgangsmåter for produkter, foreslår jeg at du ser på vår dedikerte veiledning om dette.

Beste fremgangsmåter for håndtering av sprintbackloggen

Sprintbackloggen representerer omfanget av et spesifikt inkrement. Derfor er tipsene for å håndtere den riktig litt annerledes:

• Unngå overplanlegging: Mennesker er svært dårlige til å anslå egne evner. Hvis teamet ditt forplikter seg til en betydelig større sprintbacklogg enn tidligere, bør du hjelpe dem med å fjerne et par elementer fra den.
• Håndter blokkeringer daglig: Jeg har aldri sett en problemfri sprint i løpet av karrieren min (som har bestått av hundrevis av dem). Blokkeringer vil alltid oppstå. Og hvis du ikke håndterer dem umiddelbart, synker sannsynligheten for at du fullfører sprinten kraftig. Følg derfor nøye med på hva teamet rapporterer under de daglige standupmøtene.
• Bruk spesialiserte verktøy: Internett er fullt av programvare som er utviklet for å forbedre effektiviteten og virkningen av de smidige prosessene dine. Benytt deg av dem.

Når det gjelder det siste punktet, finner du her et par verktøy med alle de viktigste funksjonene som du kan vurdere å bruke.

Atlassian Jira: Funksjonsrikt smidig verktøy for komplekse arbeidsflyter og store team.

Trello: Lettvektsverktøy for oppgavehåndtering med smidige programtillegg (Kanban og Scrum) som passer best for små oppstartsteam.

Monday.com: Det ligger mellom Jira og Trello. Det er funksjonsrikt, men støtter enkelt lettvektsprosesser og små team.

Hvis du vil vite mer, bør du ta en titt på listen vår over de beste verktøyene for produktstyring.

Vanlige fallgruver og utfordringer ved backloghåndtering

Jeg har mistet tellingen på hvor mange elendige feil jeg har gjort med håndtering av backlogene mine gjennom karrieren. Selv om det er uunngåelig å gjøre feil (det er slik man lærer), vil jeg likevel trekke frem et par betydelige feil i håp om at du unngår dem (i motsetning til meg).

Å tro at man vet alt: Dette gjelder spesielt når du er junior (hei, Dunning-Kruger-effekten). Du leser et par artikler om håndtering av backlogger og tror at du vet hvordan det skal gjøres bedre enn alle andre. Det fører nesten alltid til en stor tabbe. Så hvis det finnes mer erfarne produktledere rundt deg, må du ikke nøle med å be om hjelp. Alternativt kan du også se på eksempler på produktbacklogger som er satt opp riktig.

Å slutte å lære: Verdenen for smidig utvikling utvikler seg raskt. Hvis du slutter å lære om nye metoder og verktøy, ender du opp med å møte problemer som allerede har nye løsninger der ute. Meld deg derfor på kurs eller webinarer om smidig utvikling, og abonner på nyhetsbrevet vårt for mange ressurser og veiledninger om produktledelse.

Å tro at PM-er ikke er en del av teamet for smidig utvikling: Hvis du tror at PM-er ikke har noe å gjøre med elementene i sprinten, vil du sannsynligvis mislykkes med de fleste sprintene dine. Det oppstår alltid produktrelaterte spørsmål og behov for avklaringer under implementeringen av brukerhistorier. Jo raskere du løser dem, desto bedre kvalitet vil resultatet ha under sprintgjennomgangen.

Alt er en prioritet, og fristen var i går: Dette er også kjent som «CEO-sykdommen» og er et tegn på at backloggen din mangler prioritering. En enkel måte å begrense dette på er å ha mot til å si til CEO-en din: «Nei, vi har ikke kapasitet. Fortell meg hvilken som er viktigst.» Tro meg, de fleste CEO-er vil lytte til deg og gi deg en tydelig prioritet.