Scrum Guide | 40. Vård av produktbacklogg

Produkt Backlog vård är en av de primära uppgifterna för en Produktägare. Vårdnadsprocessen inkluderar att formulera, detaljera och lägga till nya Användarberättelser till Produkt Backloggen. Men den viktigaste av vårduppgifterna är att säkerställa att posterna i Backloggen är i rätt ordning, dvs. blir prioriterade.

Produkt Backlog vård – innehållsförteckning:

1. Introduktion
2. Syfte med Produkt Backlog vård
3. Fel i Produkt Backlog underhåll
4. Backlog underhåll vs. mätvärden som används i Scrum
5. Sammanfattning

Introduktion

Produkt Backlog är en av Scrums Artefakter. Den innehåller en prioriterad lista över arbete som behövs för att skapa en Produkt. Med andra ord, det är en lista över Användarberättelser som är nödvändiga för att uppnå Produktmålet. Du kan hitta en detaljerad beskrivning av vad Användarberättelser är i den här artikeln. Och här är detaljerna om egenskaperna och hur man underhåller Produkt Backloggen.

Produkt Backlog vård går också under följande namn:

• Backlog Prioritering,
• Backlog Förfining,
• Backlog Skalning.

Syfte med Produkt Backlog vård

Produktägaren hanterar Produkt Backloggen. Nyckelfärdigheterna inkluderar prioritering av uppgifter när deras förfallodatum närmar sig. Detta beror på att målet med Produkt Backlog vård är att säkerställa att Produktens funktioner har det högsta affärsvärdet, dvs. de som är mest väsentliga ur Kundens perspektiv, ligger högst upp på att-göra-listan. Och deras beskrivning är tydlig och detaljerad så att deras implementering kan börja direkt i nästa Sprint.

Produkt Backloggen kan uppdateras dagligen om det behövs. Produktägaren kan lägga till nya Användarberättelser till Produkt Backloggen efter att ha pratat med intressenter och utvecklingsteamet, eller genom att dra slutsatser och omformulera Användarberättelser som redan skrivits i Produkt Backloggen.

Obligatorisk uppdatering av Backloggen är en av de uppgifter som utförs under Sprint Review. Vi beskrev den processen i detalj i den här artikeln. Vanligtvis diskuterar Scrum-teamet under detta möte inte bara de uppgifter som ska slutföras i nästa Sprint. Det specificerar också preliminärt Användarberättelser och deras implementering i de kommande två eller tre Sprintarna. Detta sätt att göra saker på gör att Scrum-teamet och dess aktiviteter kan ta en bredare syn på den långsiktiga riktningen. Det möjliggör att tänka på de uppgifter som för närvarande utförs ur perspektivet av deras utveckling i efterföljande Sprintar.

Fel i Produkt Backlog underhåll

En av de vanligaste problemen angående Produkt Backlog vård är att tillåta den att expandera okontrollerat. Detta beror på att medan man arbetar med Produkten, dyker olika ytterligare funktioner och uppgifter som föreslagits av både intressenter och Scrum-teammedlemmar spontant upp. Därför är det en av de viktigaste uppgifterna som Produktägaren utför att begränsa tillväxten av Produkt Backloggens omfattning (scope creep). De vanligaste misstagen som Produktägare gör rör:

1. Avvikelse från Produktmålet – att lägga till för många idéer till Produkt Backloggen utöver det grundläggande Produktmålet är inte en bra praxis, eftersom det kraftigt minskar läsbarheten. Det fungerar bättre att samla idéer för ytterligare funktionalitet i ett separat dokument.
2. Duplicering av innehåll – att ange upprepade eller mycket liknande idéer från olika intressenter i Backloggen – innan en ny post läggs till i Backloggen bör Produktägaren säkerställa att den nya posten inte duplicerar någon av de befintliga.
3. Brist på ett bredare perspektiv – du bör ordna Produkt Backlog-poster enligt deras värde i förhållande till Produktmålet. Tänk dock på att prioritering bör ta hänsyn till de kommande flera Sprintarna så att de uppgifter som utförs i en given Sprint är sömlöst kopplade till både den föregående Sprinten och Sprinten som omedelbart följer efter den.

Du kan inte undvika misstag av detta slag. Men medvetenhet om deras förekomst kan göra Produktägaren mer försiktig när det gäller att lägga till nya Användarberättelser till Produkt Backloggen för att hitta rätt balans. Detta beror på att det också är ett misstag att ge Backloggen för mycket klipp och eliminera poster som innehåller liknande uppgifter som skiljer sig. Till exempel, att beskriva liknande Produktfunktioner som skiljer sig avsevärt i tillämpningen.

Backlog underhåll vs. mätvärden som används i Scrum

Produkt Backloggen innehåller en beskrivning av det återstående arbetet under hela projektet. Men endast en uppdaterad och regelbundet vårdad Backlog kan noggrant uppskatta förhållandet mellan mängden utfört arbete och det totala. För att avbilda mängden utfört arbete bör du tillämpa Burndown Diagrammet, som vi skrev om i den här artikeln.

En annan populär mätning för att beskriva Scrum-teamets arbete är Velocity. Du kan mäta det genom att jämföra antalet Produkt Backlog-poster som omvandlats till Increment under en enda Sprint. Vi beskrev Velocity mer i detalj i den här artikeln.

Sammanfattning

Produktägaren utför Produkt Backlog Vård. När Produkt Backloggen är väl underhållen har Scrum-teamet en tydlig bild av det arbete som återstår. Det kan också få ett bredare, framåtblickande perspektiv på hur vägen till Produktmålet ser ut. Detta är varför Produktägaren behöver säkerställa att Användarberättelserna som ingår i Produkt Backloggen är i prioritetsordning för slutförande. Och också att de uppgifter som ska slutföras i de kommande Sprintarna är beskrivna i största detalj.

Om du gillar vårt innehåll, gå med i vår aktiva community av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.