Har du nogensinde set på din backlog og haft lyst til at slette alt i den og starte forfra? Det har jeg i hvert fald følt mere end én gang, eftersom det ikke er nogen nem opgave at opbygge og vedligeholde produktbacklogs. Men for at vise dig, hvordan man håndterer backlogs korrekt, og inspirere dig til at rydde op i din egen, vil jeg dele fire fremragende eksempler på produktbacklogs med dig.
Hvad handler produktbackloggen om i agil udvikling og Scrum?
Produktbackloggen er et levende dokument, der indeholder alle de elementer, som produktteamet, scrummasteren og udviklingsteamet planlægger at arbejde på for at bygge deres produkt.
Den består af alt det, du har brug for til at bygge og vedligeholde dit produkt, herunder nye funktioner, opgaver relateret til teknisk gæld, forbedringer af tekniske processer fra din seneste retrospektiv, opgaver inden for QA-automatisering og meget mere.
Det grundlæggende kendetegn ved en produktbacklog er, at den er en prioriteret liste, hvor elementerne øverst har den højeste prioritet, og teamet bør tage dem først, når de planlægger deres sprints (eller når de har ledig plads på deres kanban-tavle).
Produktbacklog vs. sprintbacklog vs. produktkøreplan: Hvad er forskellen?
I agil projektledelse og især inden for Scrum-metodologien er en produktbacklog ikke den eneste liste over elementer, som produktejeren opretter til dit udviklingsteam. Der findes også sprintbackloggen og produktkøreplanen. Men hvad er forskellen på dem? Lad os se nærmere på det.
Sprintbacklog: Dette er en delmængde af den større backlog og indeholder kun de elementer, som Scrum-teamet har inkluderet i det næste sprint eller en anden form for iteration som resultat af et sprintplanlægningsmøde. Elementerne her er normalt velbearbejdede og indeholder story points.
Produktkøreplan: Dette er et overordnet dokument, der viser produktets vigtigste funktioner og milepæle. I modsætning til backloggen, som er mere taktisk af natur og indeholder beskrivelser af funktioner, er produktkøreplanen strategisk og har til formål at vise teammedlemmer og interessenter, hvor produktet er på vej hen, og hvilke fokusområder der har højeste prioritet.
Nu hvor du og de vigtigste begreber er blevet ordentligt introduceret, vil jeg gå direkte til at forklare, hvordan du håndterer din produktbacklog (og hvordan du, øh, ikke skal gøre det).
Sådan skal du ikke gøre: Her er et forfærdeligt eksempel på en produktbacklog
At forstå antipatterns i forbindelse med oprettelse og håndtering af produktbacklogs er sandsynligvis lige så vigtigt som at lære bedste praksisser. Grunden er, at hvis du ikke ved, at noget er et antipattern, risikerer du at have det i din backlog og tro, at det er noget normalt og almindeligt.
Lad os se på eksemplet nedenfor for at gennemgå nogle af de metoder, der i væsentlig grad kan forringe kvaliteten af din backlog.
Tilbage til eksemplet. Tag dig god tid til at undersøge det grundigt.
Det ser forfærdeligt ud, ikke? Når vi ser på denne backlog, vil de fleste af os faktisk opleve to følelser:
- Væmmelse over rodet blandt elementerne i denne backlog.
- Dårlig samvittighed, fordi lad os indrømme det: Vi har alle haft en backlog, der så sådan ud (det har jeg selvfølgelig også).
Lad os nu gennemgå problemerne i denne backlog.
Have an account? Log In
For mange elementer i produktbackloggen
Lagde du mærke til, at der var 665 problemer i denne backlog? Den største backlog, jeg har haft “fornøjelsen” af at håndtere, havde over 2.500 elementer.
Problemet med en overfyldt backlog er, at du næsten med sikkerhed ikke vil kunne huske, hvad hvert element i den handler om, og hvorfor du har placeret det på en bestemt position/prioritet i din backlog. Da du ikke har nogen idé om, hvad disse opgaver handler om, vil du sandsynligvis ikke tage dem med til din næste forfining, diskutere deres detaljer og inkludere dem i det kommende sprint.
Så ender du med et enormt, uhåndterligt rod, der bliver ved med at hobe sig op i det uendelige.
Forkert prioritering af backlog
Et andet problem, som du måske har lagt mærke til på denne backlogliste, er, at der øverst er placeret arbejdselementer med prioriteterne “Laveste” og “Lav” – over elementer med prioriteten “Højeste”.
Dette er et typisk eksempel på, hvad der sker, når din backlog ikke er prioriteret korrekt. Der kan være mange årsager til dette, men den mest sandsynlige er, at du har nedprioriteret et element med prioriteten “Høj” ved at flytte det længere ned i backloggen, men glemt at ændre prioritetsfeltet.
Author's Tip
Uanset hvorfor du er endt med rod i prioriteterne, er det noget, der kan skade dit produkt og dit team. Glem ikke, at din backlog bør fungere som en “eneste sandhedskilde” for alle. Hvis der derfor er angivet en forkert prioritet for et element (f.eks. hvis det får en højere prioritet, end det burde have), risikerer du, at dit team begynder at arbejde på det og ignorerer andre opgaver, der er vigtigere.
Manglende detaljer
Lagde du mærke til elementet, der siger “Jeg ønsker problemfri integration med alle sociale medieplatforme”? LOL. Det er ikke engang en ordentlig brugerhistorie, når man tager højde for det enorme omfang, den sigter mod. Omfanget er så stort, at du i praksis burde have flere epos, der dækker det, hvor hvert epos indeholder historierne for én social medieplatform.
Ud over det enorme omfang er problemet med dette element (faktisk med hvert element i denne backlog), at det er vagt formuleret. Brugerhistorier skal beskrive en specifik brugeroplevelse og handling.
Forestil dig, at du tager denne historie med til backlogforfiningsmødet med dit agile team. Du ville blive mødt af en strøm af spørgsmål om næsten alle aspekter af historien.
"Hvad mener du med problemfri?" "Hvordan ser integrationen ud?" "Hvilke sociale medieplatforme integrerer vi med?!"
“Jeg vil have alt, og det skal være nu”
Et andet advarselssignal, som du måske lagde mærke til i backloggen, var, at 70 % af elementerne havde prioriteten “Højeste”. Dette er endnu en typisk situation, når du udelukkende baserer dig på dine interessenters meninger, når du fastsætter prioriteter (og hver interessent anser sine egne elementer for vigtige), uden at forsøge at evaluere dem objektivt og sammenligne deres betydning med betydningen af andre elementer på listen.
Nu hvor vi har defineret, hvordan en dårlig backlog ser ud, så lad os rette op på den og gennemgå fire gode eksempler på backloger ... så du kan gøre din backlog fantastisk igen.
3 eksempler på backloger, der er gjort rigtigt
Før jeg viser dig disse eksempler, vil jeg bemærke, at der ikke findes én enkelt korrekt måde at oprette en god backlog på. Hvordan din backlog ser ud, afhænger af dit produkts karakter, dets modenhed, størrelsen på din virksomhed eller dit team osv.
I virkeligheden er en god backlog en, der kan skabe klarhed og fælles forståelse blandt alle om det aktuelle og kommende omfang af dit produkt.
Der findes dog generelle måder, hvorpå du kan håndtere din backlog, så den bliver mere organiseret og nemmere for alle at bruge. Hvert af eksemplerne nedenfor repræsenterer en sådan bedste praksis.
Eksempel nr. 1: En backlog med sektioner
Det er næsten aldrig i orden at have en backlog med hundredvis eller tusindvis af elementer. Det er dog som regel ganske almindeligt og normalt at have omkring 100 elementer. Men selv med 100 elementer i din backlog er det let at glemme, hvad hvert enkelt handler om, eller lade dem forblive uberørte i lang tid uden at føje dem til dine kommende sprinter.
For at gøre din backlog mere organiseret kan du overveje at opdele den i sektioner.
Nogle produktchefer kan lide at bruge sektioner til at gruppere elementer efter deres fokusområder eller milepæle. Personligt foretrækker jeg at bruge etiketter for Version, Epos og Komponent på opgaver til dette formål og opdele min backlog i sektioner baseret på omfanget af kommende sprinter.
Dette er en god måde at tildele et sprint (eller i det mindste en foreløbig tidsplan for implementeringen) til langt de fleste elementer i din backlog og sikre, at ingen opgaver bliver forsømt.
En anden almindelig måde at håndtere en backlog med sektioner på er at gruppere elementer baseret på deres forfinelsesstatus/arbejdsgang (det er noget, som AI i backlogstyring kan hjælpe med). I dette tilfælde strømliner du din proces med følgende sektioner:
- Aktuel sprint
- Klar til planlægning
- Klar til forfinelse
- Backlog
Det, du gør i dette tilfælde, er at tilføje produktkrav og beskrivelser til elementerne i backloggen. Når kravene er klar, sender du dem til sektionen “Klar til forfinelse”, som fungerer som dit omfang for det næste forfinelsesmøde.
Efter at have forfinet et element flytter du det til sektionen “Klar til planlægning”, hvilket angiver, at det er klar, og at teamet kan inkludere det i deres kommende sprint.
Eksempel nr. 2: En backlog med korrekt placerede komponenter, temaer og versioner
Segmentering af din backlog vil helt sikkert gøre den mere overskuelig og organiseret. Begrænsningen ved kun at bruge segmentering er dog, at du kun kan organisere din backlog ud fra ét kriterium (f.eks. sprints, forfinelsesstatus osv.).
Heldigvis giver moderne værktøjer til produktbacklogs dig et bredere udvalg af muligheder for at organisere din to-do-liste til produktudvikling baseret på flere kriterier. Se bare denne imponerende backlog.
Ser den ikke velorganiseret og behagelig ud for øjet? I dette særlige tilfælde har vi udnyttet følgende funktioner for at gøre vores backlog mere håndterbar:
Komponenter
Dette felt/denne egenskab beskriver traditionelt det område af produktet, hvor du vil tilføje den pågældende funktion. I eksemplet ovenfor er komponenterne de separate produkter, som tilsammen udgør Grammarly.
En anden almindelig måde at bruge komponenter på er at organisere historier/opgaver baseret på den teknologi, der kræves for at skabe funktionen. I webapplikationer kan du for eksempel have klient- og serverkomponenter, som hjælper dig med at organisere arbejdet og afhængighederne mellem udviklere, der er specialiserede i enten klientside- eller serversideudvikling.
Versioner/udgivelser
Med denne egenskab dokumenterer du alle de funktioner og fejlrettelser, som dit Scrum-team vil udgive med en bestemt version af dit produkt. Versionssporing i backloggen medfører to meget værdifulde fordele.
- Det hjælper dig med at planlægge dine sprints og udgivelser. Hvis du for eksempel planlægger en udgivelse om 2 uger, bør du under planlægningsmødet sørge for at inkludere alle de opgaver, der er beregnet til denne udgivelsesversion, i sprinten.
- Du kan dokumentere alt, hvad dit team har lagt i en bestemt version og nemt spore problemer tilbage, når der sker noget i produktionen.
Forestil dig for eksempel, at folk begynder at få Captcha-fejl i dit tilmeldingsforløb i den seneste version 1.3.2. Når du søger efter den opgave, som dit team baserede ændringerne af captcha-konfigurationerne på, kan du se, at den tilhører version 1.3.1. Det betyder, at du enten skal rulle tilbage til version 1.3.0 eller udføre en hotfix.
Temaer
Jeg tror ikke, jeg behøver at forklare, hvad et tema er, eller hvad fordelene ved at bruge det er. Men hvis du vil gå i dybden med bedste praksis og de fine detaljer ved temaer, kan du læse vores guide til temaer (ordspillet er tilsigtet) om emnet.
More Articles
Eksempel nr. 3: En backlog med den rette mængde detaljer for hver sektion
Dette er en bedste praksis, som du måske er stødt på i mange bøger og teoretiske tekster om agil produktstyring. Selvom vi har en tendens til at blive lidt mere skeptiske over for teoretiske begreber, jo mere erfaring vi får, er dette faktisk nyttigt i praksis.
Idéen er altså, at elementerne øverst bør have mange detaljer, og ideelt set bør du have ført dem gennem en forfinelse af produktbackloggen mindst én gang. Elementerne nederst i backloggen bør derimod have få detaljer, da der er stor sandsynlighed for, at du lærer noget nyt om dit produkt og dine slutbrugere, og at dette element bliver forældet.
Det betyder, at hvis elementet øverst i din backlog ser sådan ud (eller er endnu mere detaljeret end dette):
Dine brugerhistorier nederst i opgavelisten bør indeholde langt færre detaljer og se sådan ud:
Og de brugerhistorier og initiativer, du har midt i opgavelisten, vil have et mellemstort detaljeringsniveau.
Eksempel nr. 4: Jeg ved, det er indlysende, men … en ryddelig opgaveliste
Jeg ved, at det ikke er nemt at holde sin opgaveliste ryddelig. Jeg har selv stået i den situation mange gange, og jeg ved, at det kan føles som en pligt. Men det er afgørende for kvaliteten af din opgaveliste, at du gennemgår alt på den og husker at fjerne forældede elementer.
Det er ikke altid nemt at slette ting fra sin opgaveliste. Der findes virkelig gode funktioner, som du håber at kunne implementere en dag (primært funktioner, der er rare at have), og nogle gange har du egentlig ikke lyst til at skille dig af med dem. Men på et tidspunkt må du se det i øjnene: Du ved, at du aldrig kommer til at implementere dem. Og selv hvis du gør, vil det betyde, at du er løbet tør for funktioner med høj prioritet, hvilket generelt ikke er et godt tegn.
Nogle gange er det dine interessenter, der har oprettet disse forældede elementer på din opgaveliste. Før du fjerner dem, prøver du at spørge dem, om deres anmodning stadig er relevant, og svaret er næsten altid ja. Men hvis anmodningen er mere end 6 måneder gammel, og de allerede havde glemt den, skal du blot overbevise dem om, at det ikke er noget, der haster (hvis det var, ville de have fulgt op på det flere gange), og derefter slette den.
En god opgaveliste er den, der fungerer bedst for dig
Hvis du tog alle de bedste fremgangsmåder her i betragtning, ville du så have en god opgaveliste? De vil hjælpe, men de garanterer ikke, at den bliver fremragende.
Glem ikke, at formålet med opgavelisten er at være en fælles sandhedskilde for alle. Ud over disse bedste fremgangsmåder skal du derfor tage hensyn til dit teams og dine interessenters behov og arbejdsstil og opbygge din opgaveliste på en måde, der hjælper dem med at være på samme side.
Denne guide til gode opgavelister er en del af en større serie om alt inden for agil udvikling. Tilmeld dig vores nyhedsbrev for at få flere guider og indsigter som denne leveret til din indbakke hver anden uge!
