3 exempel på produktbackloggar som är rätt gjorda (+ vad du inte ska göra)
Har du någonsin tittat på din backlogg och velat radera allt i den och börja om från början? Det har jag gjort mer än en gång, eftersom det inte är någon enkel bedrift att bygga och underhålla produktbackloggar. Men för att visa dig hur man gör rätt med backloggar och inspirera dig att rensa upp din egen vill jag dela med mig av fyra enastående exempel på produktbackloggar.
Vad handlar produktbackloggen om inom agilt arbete och Scrum?
Produktbackloggen är ett levande dokument som innehåller alla de objekt som produktteamet, Scrum-mastern och utvecklingsteamet planerar att arbeta med för att bygga sin produkt.
Den består av allt du behöver för att bygga och underhålla din produkt, inklusive nya funktioner, uppgifter relaterade till teknisk skuld, tekniska processförbättringar från din senaste retrospektiv, uppgifter för QA-automatisering och mycket mer.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Den viktigaste egenskapen hos en produktbacklogg är att den är en prioriterad lista där objekten högst upp har högst prioritet och teamet bör ta itu med dem först när de planerar sina sprintar (eller när de har ledigt utrymme på sin kanban-tavla).
Produktbacklogg kontra sprintbacklogg kontra produktfärdplan: Vad är skillnaden?
Inom agil projektledning och särskilt Scrum-metodik är en produktbacklogg inte den enda lista över objekt som produktägaren skapar för utvecklingsteamet. Det finns också en sprintbacklogg och en produktfärdplan. Men vad är skillnaden mellan dem? Låt oss reda ut det.
Sprintbacklogg: Detta är en delmängd av den större backloggen och innehåller endast de objekt som Scrum-teamet har inkluderat i nästa sprint eller en annan typ av iteration till följd av ett sprintplaneringsmöte. Objekten här är vanligtvis väl genomarbetade och innehåller poäng för användarberättelser.
Produktfärdplan: Detta är ett övergripande dokument som visar produktens viktigaste funktioner och milstolpar. Till skillnad från backloggen, som är mer taktisk och innehåller beskrivningar av funktioner, är produktfärdplanen strategisk och syftar till att visa teammedlemmar och intressenter vart produkten är på väg och vilka fokusområden som har högst prioritet.
Nu när du och de viktigaste begreppen har presenterats ordentligt går jag direkt över till att förklara hur du hanterar din produktbacklogg (och hur du, eh, inte ska göra det).
Så här ska du INTE göra: Här är ett hemskt exempel på en produktbacklogg
Att förstå antimönstren för att skapa och hantera produktbackloggar är förmodligen lika viktigt som att lära sig bästa praxis. Anledningen är att om du inte vet att något är ett antimönster riskerar du att ha det i din backlogg och tro att det är något normalt och vanligt.
För att gå igenom några av de metoder som avsevärt kan försämra kvaliteten på din backlogg ska vi titta på exemplet nedan.
Tillbaka till exemplet. Ta dig tid att undersöka det noggrant.
Det ser hemskt ut, eller hur? Faktum är att de flesta av oss kommer att uppleva två känslor när vi tittar på den här backloggen:
- Avsky över röran bland objekten i den här backloggen.
- Skuld, eftersom vi måste erkänna att vi alla har haft en backlogg som såg ut så här (jag också, förstås).
Nu ska vi gå igenom problemen i den här backloggen.
Överflöd av objekt i produktbackloggen
La du märke till att det fanns 665 ärenden i den här backloggen? Den största backlogg jag haft ”glädjen” att hantera innehöll över 2 500 objekt.
Problemet med en överbelastad backlogg är att du nästan säkert inte kommer att kunna komma ihåg vad varje objekt i den handlar om och varför du har placerat det på en viss position eller prioritet i din backlogg. Eftersom du inte har någon aning om vad dessa uppgifter handlar om är det osannolikt att du tar upp dem vid nästa förfining, diskuterar detaljerna och inkluderar dem i den kommande sprinten.
Så till slut får du en enorm, ohanterlig röra som fortsätter att växa i all oändlighet.
Felaktig prioritering av backloggen
Ett annat problem som du kanske har lagt märke till i den här backlogglistan är att det finns arbetsobjekt med prioriteten ”Lägst” och ”Låg” placerade högst upp – ovanför objekt med prioriteten ”Högst”.
Detta är ett typiskt exempel på vad som händer när backloggen inte är korrekt prioriterad. Det kan finnas många orsaker till detta, men den mest sannolika är att du har nedprioriterat ett objekt med prioriteten ”Hög” genom att flytta ner det i backloggen, men glömt att ändra prioritetsfältet.
Brist på detaljer
Lade du märke till objektet som säger ”Jag vill ha sömlös integration med alla sociala medieplattformar”? LOL. Det är inte ens en korrekt användarberättelse, med tanke på den enorma omfattning som den siktar på. Omfattningen är så stor att du i praktiken borde ha flera epiker som täcker den, där varje epik innehåller berättelserna för en social medieplattform.
Utöver den enorma omfattningen är problemet med det här objektet (faktum är att det gäller varje objekt i den här backloggen) att det är vagt. Användarberättelser ska beskriva en specifik användarupplevelse och handling.
Föreställ dig att du tar med den här berättelsen till mötet för backloggförfining med ditt agila team. Du skulle mötas av en ström av frågor om nästan varje aspekt av berättelsen.
”Vad menar du med sömlös?” ”Hur ser integrationen ut?” ”Vilka sociala medieplattformar ska vi integrera med?!”
”Jag vill ha allt, och det nu”
En annan varningssignal som du kanske lade märke till i backloggen var att 70 % av objekten hade prioriteten ”Högst”. Detta är en annan typisk situation när du enbart förlitar dig på intressenternas åsikter när du fastställer prioriteringar (och varje intressent anser att deras objekt är viktigt), utan att försöka utvärdera dem objektivt och jämföra deras betydelse med betydelsen hos andra objekt i listan.
Nu när vi har definierat hur en dålig backlog ser ut, låt oss rätta till den och gå igenom fyra bra exempel på backloggar ... så att du kan göra din backlog fantastisk igen.
3 exempel på välfungerande backloggar
Innan jag visar dig dessa exempel vill jag påpeka att det inte finns ett enda korrekt sätt att skapa en bra backlogg. Hur din backlogg ser ut beror på vilken typ av produkt du har, dess mognadsgrad, storleken på företaget eller teamet och så vidare.
I verkligheten är en bra backlogg en backlogg som kan skapa tydlighet och samsyn bland alla kring produktens aktuella och kommande omfattning.
Det finns dock generella sätt att hantera backloggen som gör den mer organiserad och enklare för alla att använda. Vart och ett av exemplen nedan representerar en sådan god praxis.
Exempel nr 1: En backlog med avsnitt
Det är nästan aldrig okej att ha en backlogg med hundratals eller tusentals objekt. Däremot är det vanligt och normalt att ha omkring 100 objekt. Men även med hundra objekt i backloggen är det lätt att glömma vad vart och ett handlar om eller låta dem förbli orörda under lång tid utan att lägga till dem i kommande sprintar.
För att göra backloggen mer organiserad kan du överväga att dela upp den i avsnitt.
Vissa produktchefer tycker om att använda avsnitt för att gruppera objekt utifrån sina fokusområden eller milstolpar. Jag föredrar personligen att använda taggarna Version, Epik och Komponent på uppgifter för detta och dela upp backloggen i avsnitt utifrån omfattningen av kommande sprintar.
Detta är ett utmärkt sätt att tilldela en sprint (eller åtminstone en ungefärlig tidsplan för genomförandet) till de allra flesta objekten i backloggen och se till att ingen uppgift lämnas utan uppmärksamhet.
Ett annat vanligt sätt att hantera en backlogg med sektioner är att gruppera objekt baserat på deras förfiningsstatus/arbetsflöde (detta är något som AI i backlogghantering kan hjälpa till med). I det här fallet effektiviserar du processen med följande sektioner:
- Pågående sprint
- Redo för planering
- Redo för förfining
- Backlogg
Det du gör i det här fallet är att lägga till produktkrav och beskrivningar för objekten i backloggen. När kraven är klara skickar du dem till sektionen ”Redo för förfining”, som fungerar som underlag för nästa förfiningsmöte.
Efter att du har förfinat ett objekt flyttar du det till sektionen ”Redo för planering”, vilket visar att det är klart och att teamet kan inkludera det i sin kommande sprint.
Exempel 2: En backlogg med korrekt placerade komponenter, epos och versioner
Att dela upp backloggen kommer definitivt att göra den renare och mer organiserad. Begränsningen med att endast använda uppdelning är dock att du bara kan organisera backloggen utifrån ett enda kriterium (till exempel sprintarna, förfiningsstatusen och så vidare).
Lyckligtvis ger moderna verktyg för produktbackloggar dig ett bredare utbud av alternativ för att organisera din att göra-lista för produktutveckling utifrån flera kriterier. Titta bara på denna fantastiskt välordnade backlogg.
Ser den inte välorganiserad och tilltalande ut? I just det här fallet har vi utnyttjat följande funktioner för att göra backloggen mer lätthanterlig:
Komponenter
Detta fält/denna egenskap beskriver traditionellt det område i produkten där du vill lägga till den aktuella funktionen. I exemplet ovan är komponenterna de separata produkter som tillsammans utgör Grammarly.
Ett annat vanligt sätt att använda komponenter är att organisera berättelser/uppgifter baserat på den teknik som krävs för att skapa funktionen. För webbapplikationer kan du exempelvis ha komponenterna Klient/Server för att hjälpa dig organisera arbetet och beroendena mellan ingenjörer som är specialiserade på antingen utveckling på klientsidan eller serversidan.
Versioner/utgåvor
Med denna egenskap dokumenterar du alla funktioner och felkorrigeringar som ditt Scrum-team kommer att lansera med en viss version av produkten. Versionsspårning i backloggen medför två mycket värdefulla fördelar.
- Det hjälper dig att planera dina sprintar och utgåvor. Om du till exempel planerar en utgåva om två veckor bör du under planeringsmötet se till att inkludera alla uppgifter som är avsedda för den utgåveversionen i sprinten.
- Du kan dokumentera allt som ditt team har lagt in i en viss version och enkelt spåra tillbaka problem när något händer i produktion.
Föreställ dig till exempel att användare börjar få CAPTCHA-fel i registreringsflödet i den senaste versionen 1.3.2. När du söker efter uppgiften som teamet utgick från när det ändrade CAPTCHA-konfigurationerna ser du att den tillhör version 1.3.1. Det innebär att du antingen måste återgå till version 1.3.0 eller göra en snabbkorrigering.
Epos
Jag tror inte att jag behöver förklara vad ett epos är eller vilka fördelar det har att använda ett. Men om du vill fördjupa dig i bästa praxis och detaljerna kring epos kan du läsa vår guide om epos (ordvitsen är avsiktlig).
More Articles
Exempel 3: En backlogg med rätt mängd detaljer för varje sektion
Detta är en bästa praxis som du kanske har stött på i många böcker och teoretiska texter om agil produktledning. Även om vi tenderar att bli något mer skeptiska till teoretiska koncept ju mer erfarenhet vi får, är detta faktiskt användbart i praktiken.
Idén är alltså att objekten högst upp bör ha många detaljer och helst bör du ha tagit dem genom en förfining av produktbackloggen åtminstone en gång. Objekten längst ned i backloggen bör däremot ha få detaljer, eftersom sannolikheten är stor att du lär dig något nytt om produkten och slutanvändarna och att objektet blir inaktuellt.
Det innebär att om objektet högst upp i backloggen ser ut så här (eller till och med är mer detaljerat än detta):
Dina berättelser längst ned i din backlogg bör innehålla betydligt färre detaljer och se ut så här:
Och de berättelser och initiativ du har i mitten av din backlogg kommer att ha en medelhög detaljnivå.
Exempel 4: Jag vet att det är uppenbart, men … en ren backlogg
Jag vet att det inte är lätt att hålla din backlogg ren. Jag har varit med om det många gånger och vet att det kan kännas som ett besvär. Att inte gå igenom allt i din backlogg och komma ihåg att ta bort föråldrade objekt är dock viktiga faktorer som avgör kvaliteten på din backlogg.
Det är inte alltid lätt att ta bort saker från din backlogg. Det finns verkligen trevliga funktioner där ute som du hoppas kunna göra någon gång (främst sådant som är bra att ha), och ibland vill du egentligen inte göra dig av med dem. Men vid en viss punkt måste du inse att du aldrig kommer att implementera dem. Och även om du gör det skulle det innebära att du har slut på funktioner med hög prioritet, vilket i allmänhet inte är ett gott tecken.
Ibland är det dina intressenter som har skapat dessa föråldrade objekt i din backlogg. Innan du tar bort dem försöker du fråga dem om deras önskemål fortfarande gäller, och svaret är nästan alltid ja. Om önskemålet är mer än 6 månader gammalt och de redan hade glömt bort det, kan du helt enkelt övertyga dem om att det inte är något brådskande (om det hade varit det skulle de ha följt upp det flera gånger) och ta bort det.
En bra backlogg är den som fungerar bäst för dig
Om du tog hänsyn till alla bästa praxis här, skulle du då ha en bra backlogg? De kommer att hjälpa, men de garanterar inte att den blir utmärkt.
Glöm inte att syftet med backloggen är att vara en enda sanningskälla för alla. Så utöver dessa bästa praxis behöver du ta hänsyn till teamets och intressenternas behov och arbetssätt och bygga din backlogg på ett sätt som hjälper dem att hålla sig uppdaterade med varandra.
Den här guiden om bra backloggar är en del av en större serie om allt inom agilt arbete. Prenumerera på vårt nyhetsbrev för fler guider och insikter som denna, levererade varannan vecka till din inkorg!
