Produktbacklog kontra sprintbacklog: Vigtige forskelle

Backlogge er rygraden i agile arbejdsgange og guider teams fra idéer til eksekvering. Men en almindelig faldgrube er ikke at skelne mellem produktbacklogs og sprintbacklogs—en fejl, der kan føre til fejljusterede prioriteter, ineffektive sprints og frustrerede teams.

Selvom mange af os har erfaring med at arbejde med software til backlogstyring, kan forkert brug af disse to forskellige værktøjer skabe mere forstyrrelse end klarhed.

Så hvordan sikrer vi, at vores backlogs arbejder for os og ikke imod os? At forstå deres unikke roller handler ikke kun om definitioner—det handler om at løse almindelige problemer i arbejdsgangen og optimere teamsamarbejdet. Lad os gennemgå deres forskelle og undersøge, hvordan de bruges effektivt.

Hvad er et produktbacklog?

En kort og forenklet forklaring på, hvad et produktbacklog er – det er alle de funktioner og aktiviteter, som du og dit udviklingsteam planlægger at arbejde på.

For en mere struktureret definition kan vi se på Atlassian.

Du har måske bemærket, at folkene hos Atlassian fremhævede to vigtige begreber, da de definerede backlogget.

1. Det er prioriteret.

Hvis man laver en simpel liste over ting, der skal bygges, vil det enten resultere i et stort rod eller i et produkt, der ikke er i stand til at løse brugernes problemer ordentligt. En liste over funktioner er derfor ikke rigtig et produktbacklog, medmindre du prioriterer den.

2. Det er afledt af produktkøreplanen.

Jeg har set så mange backlogs, der ganske enkelt var resultatet af, at alle delte deres idéer til funktioner og tilføjede dem til backlogget. Det resulterer i et rod og et produkt, der ligner Frankensteins monster. Hvis du vil have, at dine backlogelementer skal opnå et specifikt produkt- eller forretningsmål, skal du opbygge backlogget baseret på din produktkøreplan og din produktvision.

Det primære formål med overhovedet at have et backlog er at skabe én fælles sandhedskilde for alle i virksomheden. Der bør altid kun være ét backlog, og alle bør tage udgangspunkt i det, når de beslutter, hvad de skal gøre som det næste.

Derudover er produktbacklogget også et fremragende værktøj til at lette prioriteringen for dig og dine interessenter, eftersom du har alt, hvad du skal gøre, samlet i én enkelt liste.

Hvad bør et backlog indeholde?

Hvis du bruger en af de agile metoder, vil dit produktbacklog bestå af følgende elementer:

• Store funktioner: Store funktioner, der hjælper dig med at nå specifikke produktmål, såsom at øge konverteringen, løse et specifikt brugerproblem eller forbedre brugerens rejse gennem dit produkt. Kommentarfunktionen i Google Docs er et eksempel på dette. Store funktioner består typisk af mindre “underfunktioner”, der kaldes brugerhistorier.
• Brugerhistorier: Små funktioner eller elementer af en funktion, som dine kunder kan bruge. I Google Docs-funktionen ovenfor ville “at nævne nogen i en kommentar” eller “at løse en kommentar” være typiske eksempler på historier under denne store funktion.
• Tekniske opgaver: Arbejdsopgaver, som dit udviklingsteam skal udføre, og som ikke er relateret til funktionerne i dit backlog. Eksempler på sådanne opgaver er opsætning af en backupdatabase, refaktorering af en mikrotjeneste eller optimering af forespørgselshastigheder.
• Fejl: Det er ikke et rigtigt backlog, hvis der ikke er fejl i det. Uanset hvor godt du udvikler og tester dine funktioner, vil disse små parasitter altid dukke op. Derfor skal du opbevare, holde styr på og håndtere dem et sted. Den bedste praksis er at gemme dem i dit backlog og prioritere dem på samme måde som alle andre backlogelementer.

Sådan vil et typisk produktbacklog se ud:

P.S. Læs vores artikel om 3 eksempler på et produktbacklog, der er lavet rigtigt, hvis du leder efter mere vejledning.

Lad os nu forstå produktchefens rolle i arbejdet med backlogget.

Hvem er ansvarlig for at administrere backlogget?

Kort sagt er produktchefen backloggens gud. Vedkommende har nøglerne til, hvad der bliver bygget, i hvilken rækkefølge og hvorfor. Backloggen er deres domæne, og de er i sidste ende ansvarlige for at sikre, at den forbliver i overensstemmelse med produktvisionen, brugernes behov og forretningsmålene.

Det betyder ikke, at produktchefen er den eneste, der arbejder med backloggen. Ingeniører, designere og andre teammedlemmer kan foreslå eller endda tilføje elementer, men alle ændringer bør ske under produktchefens opsyn. En kaotisk backlog fører trods alt til et kaotisk produkt.

En produktchefs vigtigste ansvarsområder for backloggen omfatter:

• Prioritering af backloggen – Sikre, at det mest værdifulde og virkningsfulde arbejde håndteres først.
• Forfinelse af den sammen med teamet – Regelmæssigt gennemgå, opdatere og nedbryde elementer for at holde arbejdet klart og handlingsorienteret.
• Kommunikation af backlogprioriteter og ændringer – Holde interessenter informeret, så der ikke opstår overraskelser.

Fordi backloggen er et levende dokument, udvikler den sig konstant. Nye idéer opstår, prioriteter ændrer sig, og nogle funktioner bliver helt fjernet. Denne fleksibilitet er et centralt princip i agile metoder – backloggen bør afspejle de seneste realiteter og ikke en rigid, forældet plan.

En velforvaltet backlog er ikke blot en opgaveliste; det er et strategisk værktøj, der hjælper teams med at bygge det rigtige produkt på det rigtige tidspunkt. Og i centrum for det hele? Produktchefen, der holder nøglerne.

Oprettelse og håndtering af en produktbacklog 101

Du begynder at opbygge den første version af din backlog, så snart din produktkøreplan er færdig. Du vil normalt tage alle de væsentlige funktioner og arbejdsdele fra køreplanen og omdanne dem til epics i backloggen.

Derefter begynder du at udarbejde dine produktkravsdokumenter for hver af dem og opretter epics baseret på opdelingen af funktionaliteten i dit PRD.

Men som en naturlig konsekvens af produktudvikling ender du med konstant at ændre disse epics, tilføje selvstændige brugerhistorier og fejl for at få en backlog, der ligner den, de fleste af os arbejder med. Jeg mener, en rodet backlog.

Men det er forholdsvis nemt at vedligeholde din backlog, hvis du.

• Afholder regelmæssige sessioner med forfinelse af backloggen.
• Afsætter tid i den næste sprint til at gennemføre omfattende fejlrettelser og rydde op i de fejl, der findes i din backlog.
• Undlader at lade alle tilføje deres idéer til backloggen uden først at rådføre sig med dig.
• Konstant prioriterer din backlog.
• Bruger kortlægning af brugerhistorier for at få et klart overblik over, hvad der skal gøres.

Hvad angår det sidste punkt, er der to primære prioriteringsteknikker, som jeg vil foreslå, at du bruger, baseret på min omfattende erfaring med at afprøve et dusin af dem.

MoSCoW

Dette er en forholdsvis enkel teknik, der grupperer elementer i backloggen i disse tre kategorier:

• Skal-have: Når funktionen er en del af en central brugerrejse, og du ikke kan løse brugernes problemer uden den. Spotify-playlister er for eksempel et skal-have.
• Bør-have: En betydelig forbedring af brugerrejsen. I Spotifys tilfælde ville det være muligheden for at søge efter færdiglavede playlister til dit humør eller din aktivitet.
• Kan-have: Noget, der glæder brugeren, men hvis fravær ikke er afgørende. Spotify kunne bruge bevægelser til at skifte sang i stedet for knapper.
• Vil-ikke-have: Funktioner eller initiativer, som du, dine interessenter eller dit team vurderede som unødvendige under forfinelses- eller prioriteringsmøder.

Som du kan se, er MoSCoW en forholdsvis enkel teknik. Og det er en af grundene til, at jeg godt kan lide at bruge den, fordi den er meget nem at forklare for alle i rummet og få dem til også at bruge den, når de udvælger opgaver med lav eller høj prioritet fra listen over elementer, du arbejder på.

Kano

En anden enkel teknik, der lader dig se på de pågældende funktioner ud fra dine brugeres behov. Her grupperer du dine funktioner i disse kategorier:

• Grundlæggende behov: Fraværet af dette er afgørende for brugeren. På et hotelværelse ville det være, at der er rene lagner på sengen.
• Ydelsesbehov: Funktioner, hvis antal eller tilstedeværelse direkte øger brugerens tilfredshed. Det er hotelværelsets indretning eller tilstedeværelsen af vaske- eller morgenmadstjenester.
• Begejstringsbehov: Fraværet af disse vil ikke mindske tilfredsheden. Men deres tilstedeværelse vil helt sikkert øge den. Det er den søde håndklædesvane i form af en svane på sengen på hotelværelset.

Her er en graf, der illustrerer sammenhængen mellem disse typer funktioner og brugertilfredshed i Kano-modellen.

For at opsummere er produktbackloggen teamets to-do-liste, som produktchefen (eller produktteamet) opretter og vedligeholder ved hjælp af en lang række værktøjer og teknikker til backlogstyring.

Hvad er en sprintbacklog?

Nu hvor selve produktbackloggens karakter er klar for os, kan vi forstå, hvad sprintbackloggen handler om (tip: den involverer ikke motion.)

Scrum.org definerer sprintbackloggen som den delmængde af produktbackloggen, som scrumteamet har udvalgt til at færdiggøre under den kommende sprint. I scrumrammeværket er den en af de centrale scrumartefakter, som hele teamet arbejder med.

Som definitionen antyder, er sprintbackloggens primære formål klart at definere omfanget af det arbejde, som teamet skal fokusere på under sprinten.

Processen med at opbygge sprintbackloggen finder normalt sted under mødet om sprintplanlægning. Her vil du typisk se følgende aktiviteter:

1. Produktchefen definerer sprintens mål.
2. Teamet begynder at udvælge en realistisk liste over leverancer, der kan hjælpe dem med at nå dette mål.
3. Teamet opdeler brugerhistorier i tekniske opgaver og estimerer dem.
4. De ser på deres kapacitet og hastighed fra tidligere sprinter for at validere, at sprintbackloggen er realistisk.

I modsætning til produktbackloggen, hvor PM'en er eneansvarlig, ligger ansvaret for at oprette og vedligeholde sprintbackloggen hos scrumteamet. Da det er dem, der udfører de opgaver, der kræves for at opbygge funktionerne, er de bedst egnet til at afgøre sprintbackloggens størrelse og omfang.

I modsætning til mange andre scrumartefakter, som nogle teams måske vælger at ignorere (det er helt i orden; du tilpasser scrum til dit team og ikke omvendt), ser sprintbackloggen ud til at være den, som næsten alle bruger. Det er der gode grunde til. Mere specifikt giver sprintbackloggen dig:

• Klart omfang: Teamet har en ordentlig forståelse af det arbejde, de forventes at udføre i den næste iteration.
• Forbedret fokus: Med et klart arbejdsomfang og en scrum master, der bekæmper alles forsøg på at tilføje nye opgaver til sprinten, behøver teamet ikke at fokusere på andet end punkterne i sprintbackloggen.
• Bedre fremdriftssporing: Da der ikke kommer punkter ind i eller forsvinder fra sprintbackloggen, er det forholdsvis nemt at se, hvor godt teamet bevæger sig hen imod sprintmålet.

Hvad angår det tredje punkt, har de fleste Agile-værktøjer indbyggede rapporteringsværktøjer til sprinter, som automatisk sporer dit teams fremdrift for dig. En af de mest populære rapporter til dette formål er et nedbrændingsdiagram.

Denne graf består af to linjer, der bevæger sig nedad. Den grå linje er den hypotetiske ideelle fremdrift for dit team. Den røde linje er derimod den faktiske fremdrift. Jira (værktøjet, der vises på skærmbilledet) måler disse linjer baseret på det samlede antal storypoint, som dit team mangler at færdiggøre. Når nogen derfor lukker en opgave, falder den røde linje med et antal, der svarer til den estimerede mængde storypoint for opgaven.

Oprettelse og håndtering af en sprintbacklog

Processen med at oprette en sprint-backlog begynder med en produkt-backlog, der endnu ikke er blevet gennemgået. Produktejere afholder regelmæssige møder om gennemgang af backloggen (også kaldet oprydning), hvor teamet:

• Stiller PM’en spørgsmål om designet og kravene for at få en klar forståelse af, hvad produktteamet forventer, at de skal bygge.
• Udfordrer nogle af punkterne i kravene, hvis de er tidskrævende at udvikle eller vil medføre tekniske vanskeligheder.
• Fordeler ansvaret for hvert punkt i backloggen til den teamkollega, som de mener passer bedst til den pågældende opgave.
• Estimerer opgavens eller brugerfortællingens størrelse ved hjælp af en af de populære teknikker, såsom Fibonacci-tal kombineret med planlægningspoker.

Hvis vi antager, at teamet har gennemgået tilstrækkeligt mange opgaver til den næste iteration, afholder teamet et sprintplanlægningsmøde, hvor de forpligter sig til en bestemt mængde opgaver fra produkt-backloggen. I det øjeblik teamet forpligter sig til dem og starter sprintet, bliver denne gruppe af opgaver til sprint-backloggen.

Til håndtering af sprint-backloggen giver den agile metode os flere værktøjer, herunder:

• Daglige standupmøder, hvor hvert teammedlem viser sine fremskridt til teamet og rapporterer eventuelle forhindringer, der sinker dem.
• Burndown- og burnup-diagrammer, der visualiserer teamets samlede fremskridt.
• Demomøder i slutningen af sprintet, hvor teamet fremviser resultaterne af deres arbejde for produktteamet og får brugbar feedback på designet og funktionaliteten af de funktioner, de har bygget.

Endelig har vi retrospektive møder. De hjælper dig ikke direkte med at håndtere din sprint-backlog, men du får mulighed for at diskutere de processer, der vil forbedre kvaliteten og effektiviteten af håndteringen af den.

Vigtige forskelle mellem produkt-backlogs og sprint-backlogs

For bedre at forstå forskellene mellem disse tilsyneladende ensartede begreber vil jeg først give dig en sammenligning af, hvordan de adskiller sig, og derefter forklare hvert element mere detaljeret.

Selvom selve oversigten nemt kan forklare, hvordan de adskiller sig, har du måske stadig spørgsmål om bestemte aspekter. Så lad mig gennemgå dem én efter én.

Tidsramme: Produkt-backlogs repræsenterer din mellem- til langsigtede plan, da de afspejler din produktkøreplan og vision. Derfor kan planlægningshorisonten variere fra flere sprints til et par år.

Sprint-backlogs har derimod en meget kort tidsramme, da de repræsenterer de punkter, som dit team planlægger at levere i det næste sprint (som normalt varer 1-4 uger).

Ejerskab: Som vi allerede har nævnt, er den ultimativt ansvarlige for produkt-backloggen en person fra produktteamet (som regel den produktejer, der er tilknyttet teamet). Scrum-teamet kan bidrage til backloggen, men de kan kun gøre det gennem PM’en.

Situationen er anderledes med sprint-backloggen. Den eneste måde, en PM kan påvirke den på, er ved at fastsætte sprintmålet. Bortset fra det er det scrum-teamet, der har bemyndigelsen til at oprette og administrere den.

Detaljeringsgrad: Da elementerne i en produkt-backlog kan repræsentere arbejdet i flere kvartaler eller endda år, er det ikke realistisk for PM’en at have hvert element beskrevet i detaljer. Faktisk fraråder jeg det kraftigt, eftersom der altid er en risiko for, at du ender med at slette mange funktioner fra den, og det ville være spild af tid at beskrive dem minutiøst.

Normalt vil du have en høj detaljeringsgrad for elementerne med den højeste prioritet og en grov beskrivelse af alt andet.

For at brugerfortællingerne kan komme ind i sprint-backloggen, skal de dog indeholde alle relevante detaljer. Ellers vil scrum-teamet nægte at implementere brugerfortællingerne, hvis de ikke har en klar forståelse af, hvad der forventes af dem.

Formål: Produkt-backloggen er mellemleddet mellem meget vage strategiske planer og meget specifikke tekniske implementeringsdetaljer. Den fungerer som dit værktøj til at udtrykke dine strategiske planer i form af en to-do-liste.

Sprint-backlogs er derimod meget taktiske af natur og har til formål at give teamet en klar kortsigtet handlingsplan og et tydeligt omfang.

Fleksibilitet: Produkt-backlogs er levende dokumenter, der ændrer sig hele tiden. På grund af deres langsigtede natur er de nødt til at ændre sig baseret på nye prioriteter, brugerfeedback og markedsforhold, så dit produkt forbliver levedygtigt.

Sprint-backlogs er den diametrale modsætning til dette. Selvom jeg kraftigt opfordrer dig til løbende at videreudvikle produkt-backloggen, er det helt uacceptabelt at ændre elementerne i en sprint-backlog, da du ellers ender med at bryde alle teamets forpligtelser og planer.

Sådan fungerer produkt-backloggen og sprint-backloggen sammen

Som nævnt er sprintbackloggen den mere præcise og afklarede delmængde af produktbackloggen. Du betragter den stadig som en del af backloggen, indtil dit aktuelle sprint er afsluttet. Derefter forlader de færdige historier backloggen, mens de ufuldstændige historier kommer tilbage øverst på prioritetslisten.

Når det gælder funktionernes flow mellem disse to backlogs, fylder du altså ikke kun sprintbackloggen med elementer fra produktbackloggen, men kan også gøre det modsatte.

Uanset hvilken vej historierne bevæger sig, er det afgørende at sikre en problemfri overdragelse. Her er det, jeg foreslår, at du er opmærksom på:

• Alt, hvad der kommer ind i sprintbackloggen, bør indeholde åbne spørgsmål til scrumteamet. Ellers bliver du en blokering for sprintets fremdrift. Den bedste måde at håndtere dette på er at udarbejde en Definition af klarhed (DoR)-liste sammen med dit team og følge den.
• Alt, hvad der kommer ind i sprintbackloggen, bør have estimater. Ellers bliver dit teams forpligtelser og planer ukorrekte. Det vil også være vanskeligt at bruge nedbrændingsdiagrammer til at overvåge fremdriften.
• Når du opbygger sprintbackloggen, skal du altid spørge teamet tydeligt, om de er trygge ved arbejdsbyrden. Folk har en tendens til at overbelaste sig selv og ender med sprints, der kun er halvt færdige.
• Når du tager ufuldstændige elementer ud af sprintet ved dets afslutning, skal du altid følge op på det under retrospektivmødet. På den måde kan du finde ineffektivitet i processen og eliminere den.

Overordnet set ser hele processen sådan ud.

Ud over tips til at forbinde disse to vil jeg hjælpe dig med at administrere dem korrekt med et par bedste praksisser fra min erfaring.

Bedste praksisser for administration af produktbackloggen

At eje en produktbacklog kan enten være glædeligt eller forfærdeligt, afhængigt af hvor godt du administrerer den. Her er, hvad jeg gør baseret på mange års erfaring:

• Konstant oprydning: Find modet til at fjerne elementer fra backloggen, som det er meget usandsynligt vil nå frem til udvikling.
• Kommunikation med interessenter: Afhold regelmæssige prioriteringsmøder på højt niveau med dine interessenter. På den måde stemmer planen i deres hoveder overens med det, du har i backloggen.
• Separat liste til elementer med en usikker fremtid: Nogle gange får du eller en interessent idéer, som måske bliver bygget, og måske ikke. For at undgå at fylde din backlog med dem skal du opbevare dem på en separat liste et sted. Føj dem kun til backloggen, når du ved, at I kommer til at bygge dem.

Endelig foreslår jeg, at du gør brug af de mange værktøjer og skabeloner til produktbacklogs, der findes, for at fremskynde oprettelsesprocessen. Her er en samling fra ClickUp, som du kan bruge.

Hvis du gerne vil læse om flere bedste praksisser inden for produkter, foreslår jeg, at du ser vores dedikerede guide om emnet.

Bedste praksisser for administration af sprintbackloggen

Sprintbackloggen repræsenterer omfanget af et specifikt inkrement. Derfor er tipsene til at administrere den korrekt lidt anderledes:

• Undgå overplanlægning: Mennesker er dårlige til at vurdere deres egne evner. Hvis dit team forpligter sig til en betydeligt større sprintbacklog end tidligere, bør du hjælpe dem med at fjerne et par elementer fra den.
• Håndter blokeringer dagligt: Jeg har aldrig set et problemfrit sprint i løbet af min karriere, som har omfattet hundredvis af dem. Der vil altid opstå blokeringer. Og hvis du ikke håndterer dem med det samme, falder sandsynligheden for, at du gennemfører sprintet, drastisk. Vær derfor meget opmærksom på, hvad dit team rapporterer under de daglige standupmøder.
• Brug specialiserede værktøjer: Internettet er fyldt med software, der er udviklet til at forbedre effektiviteten og virkningen af dine agile processer. Gør brug af dem.

Med hensyn til det sidste punkt er her et par værktøjer med alle de nødvendige funktioner, som du kan overveje at bruge.

Atlassian Jira: Agilt værktøj med mange funktioner til komplekse arbejdsgange og store teams.

Trello: Letvægtsværktøj til opgavestyring med agile-udvidelser (Kanban og Scrum), som er bedst egnet til små opstartsteams.

Monday.com: Det ligger mellem Jira og Trello. Det har mange funktioner, men understøtter nemt letvægtsprocesser og små teams.

Hvis du vil vide mere, kan du se vores liste over de bedste værktøjer til produktstyring.

Almindelige faldgruber og udfordringer ved håndtering af backlog

Jeg har mistet overblikket over, hvor mange elendige fejl jeg har begået i forbindelse med håndteringen af mine backlogs gennem min karriere. Selvom det er uundgåeligt at begå fejl (det er sådan, man lærer), vil jeg stadig gerne fremhæve et par væsentlige fejl i håbet om, at du vil undgå dem (i modsætning til mig).

At tro, man ved alt: Dette gælder især, når man er junior (hej Dunning-Kruger-effekten). Du læser et par artikler om håndtering af backlogs og tror, at du ved, hvordan det skal gøres bedre end alle andre. Det fører næsten altid til en stor fiasko. Så hvis der er mere erfarne produktchefer omkring dig, skal du ikke tøve med at bede om deres hjælp. Alternativt kan du også se eksempler på produkt-backlogs, der er udarbejdet korrekt.

At holde op med at lære: Den agile verden udvikler sig hurtigt. Hvis du holder op med at lære om nye metoder og værktøjer, ender du med at stå over for problemer, der allerede findes nye løsninger på. Så tilmeld dig kurser eller webinarer om agil udvikling, og tilmeld dig vores nyhedsbrev med masser af ressourcer og vejledninger om produktledelse.

At tro, at PM'er ikke er en del af det agile team: Hvis du tror, at PM'er ikke har noget at gøre med elementerne i sprintet, vil du højst sandsynligt mislykkes med de fleste af dine sprints. Der opstår altid produktrelaterede spørgsmål og behov for afklaringer under implementeringen af historier. Jo hurtigere du løser dem, desto bedre kvalitet vil resultatet have ved sprintgennemgangen.

Alt er en prioritet, og deadline var i går: Dette er også kendt som “CEO-sygdommen” og er et tegn på, at din backlog mangler prioritering. En nem måde at afhjælpe dette på er at have modet til at sige til din CEO: “Nej, vi har ikke kapaciteten. Fortæl mig venligst, hvilken der er vigtigst”. Tro mig, de fleste CEO'er vil lytte til dig og give dig en klar prioritet.